Wednesday, August 20, 2008

Re: [HACKERS] Patch: plan invalidation vs stored procedures

On Wed, Aug 20, 2008 at 09:16:56AM -0400, Andrew Sullivan wrote:
> On Wed, Aug 20, 2008 at 03:12:43PM +0300, Asko Oja wrote:
>
> > - If there is nothing that can be done in 8.3 at least warning should be
> > added into the documentation. It will be just one more don't in our long
> > list don'ts for our developers.
>
> I am in favour of that change in the 8.3 branch.
+1

>
> >
> > ERROR: cache lookup failed for function.
> > - Could the plan be marked as invalid so it would fail only once so the next
> > call to the function would get replanned and work again. At least it would
> > be better than losing parts of application for indeterminate time.
>
> That seems to me to be a behaviour change, not a bug fix. I agree
> that the current behaviour is pretty annoying. That is not the same
> thing as "a bug" except in the loosest sense. The system works as
> specified, and therefore it's not a bug. If the specification is
> wrong, you need a new specification; that's a "bug fix" that is
> usually pronounced "major release".
>
> > - Could some less dangerous looking mechanism be added to 8.3 that wouldn't
> > make users not used to PostgreSQL limitations gasp for air when they see the
> > workarounds :)
>
> I think it a very bad idea even to suggest that we start undertaking
> things like adding mechanisms to minor releases, even with smileys at
> the end of the sentence. I appreciate (possibly more than many
> hackers) the limitations that are imposed on users by some of the
> decisions historically taken by developers in some of the previous
> major releases. But I very strongly agree with Dimitri: the
> super-conservative approach to maintenance releases that this project
> takes is a really big benefit to users, and is ultra important in
> "mission critical" environments. Otherwise, it becomes practically
> impossible to get minor releases into production. If you have to
> worry about the possibility of major changes between minor versions,
> you will have to treat every release as a major release.
>
+10

This policy has allowed us to upgrade to new minor releases with a
minimum of testing for critical systems and basically none for non-
critical systems. We would never upgrade for minor releases if this
changes. We do not have the resources to perform full regression
tests without having a very big carrot such as the new features a
major release contains.

Cheers,
Ken

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

No comments: