Re: change in LOCK behavior

Bruce Momjian <bruce(at)momjian(dot)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.

regards, tom lane