Re: change in LOCK behavior - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: change in LOCK behavior
Date
Msg-id 20121011021242.GI11890@momjian.us
Whole thread Raw
In response to Re: change in LOCK behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Oct 10, 2012 at 10:01:30PM -0400, Tom Lane wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > On Wed, Oct 10, 2012 at 09:29:16PM -0400, Tom Lane wrote:
> >> In what way would somebody be relying on the 9.2 behavior?
> 
> > I don't know.  I am just asking if an application could be relying on
> > the 9.2 behavior.
> 
> I don't think so.  Robert suggested in the original discussion that
> there could be cases where users would notice if the plan snapshot was
> different from the execution snapshot, but on reflection I consider that
> argument bogus.  We have these categories of snapshot-dependent things
> that happen before execution starts:
> 
> * System examination of table DDL.  This is all done with SnapshotNow
> and after acquiring a lock on the table, so it's secure.
> 
> * Evaluation of the input functions for user-defined types and domains
> (the latter of which can invoke nearly arbitrary code via CHECK
> constraints).  In principle you could imagine that one of these
> datatypes or domain check constraints involves looking at the tables
> that the surrounding query is going to touch, but I don't think anybody
> would consider that good programming style, much less expect that it
> would necessarily see exactly the same table state as query execution
> does.
> 
> * Evaluation of IMMUTABLE functions at plan time.  If such a function
> actually cares exactly which snapshot it runs with, then it's not very
> immutable, and I feel no compunction about breaking it.
> 
> * Evaluation of STABLE functions at plan time for estimation purposes.
> Such a function might well get different answers depending on which
> snapshot it uses --- but the result is only used for estimation
> purposes.  The worst possible consequence is an inferior plan; there is
> no correctness issue.
> 
> So it seems to me to be pretty difficult to credit that any of these
> things would care at all whether they saw the exact same snapshot that
> query execution does.  It's even less plausible that somebody would have
> created such a dependency in the short time 9.2 has been out, when such
> code could not have worked in any prior release.

Thanks.  You have covered all I was asking.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: change in LOCK behavior
Next
From: Bruce Momjian
Date:
Subject: Re: Warnings from fwrite() in git head