Re: Patch: plan invalidation vs stored procedures

From: Kenneth Marshall <ktm(at)rice(dot)edu>
To: Andrew Sullivan <ajs(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Patch: plan invalidation vs stored procedures
Date: 2008-08-20 13:25:24
Message-ID: 20080820132524.GQ18572@it.is.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2008-08-20 13:26:02 Re: proposal sql: labeled function params
Previous Message Andrew Sullivan 2008-08-20 13:16:56 Re: Patch: plan invalidation vs stored procedures