On Wed, Oct 10, 2012 at 10:01:30PM -0400, Tom Lane wrote: > Bruce Momjian <br...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
