Re: change in LOCK behavior

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Tomas Vondra <tv(at)fuzzy(dot)cz>, Thom Brown <thom(at)linux(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: change in LOCK behavior
Date: 2012-10-11 02:12:42
Message-ID: 20121011021242.GI11890@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 10, 2012 at 10:01:30PM -0400, Tom Lane wrote:
> 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.

Thanks. You have covered all I was asking.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2012-10-11 02:16:39 Re: [PATCH 8/8] Introduce wal decoding via catalog timetravel
Previous Message Tom Lane 2012-10-11 02:01:30 Re: change in LOCK behavior