On 2013-06-05 18:56:28 -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > Now, I did find a couple that I thought should probably stick with > > SnapshotNow, specifically pgrowlocks and pgstattuple. Those are just > > gathering statistical information, so there's no harm in having the > > snapshot change part-way through the scan, and if the scan is long, > > the user might actually regard the results under SnapshotNow as more > > accurate. Whether that's the case or not, holding back xmin for those > > kinds of scans does not seem wise. > > FWIW, I think if we're going to ditch SnapshotNow we should ditch > SnapshotNow, full stop, even removing the tqual.c routines for it. > Then we can require that *any* reference to SnapshotNow is replaced by > an MVCC reference prior to execution, and throw an error if we actually > try to test a tuple with that snapshot.
I suggest simply renaming it to something else. Every external project that decides to follow the renaming either has a proper usecase for it or the amount of sympathy for them keeping the old behaviour is rather limited. > If they really want that sort of uncertain semantics they could use > SnapshotDirty, no? Not that happy with that. A scan behaving inconsistently over its proceedings is something rather different than reading uncommitted rows. I have the feeling that trouble is waiting that way. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
