On Fri, Jul 19, 2013 at 1:27 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Noah Misch <n...@leadboat.com> writes: >> To me, the major advantage of removing SnapshotNow is to force all >> third-party code to reevaluate. But that could be just as well >> achieved by renaming it to, say, SnapshotImmediate. If there are >> borderline-legitimate SnapshotNow uses in our code base, I'd lean >> toward a rename instead. Even if we decide to remove every core use, >> third-party code might legitimately reach a different conclusion on >> similar borderline cases. > > Meh. If there is third-party code with a legitimate need for > SnapshotNow, all we'll have done is to create an annoying version > dependency for them. So if we think that's actually a likely scenario, > we shouldn't rename it. But the entire point of this change IMO is that > we *don't* think there is a legitimate use-case for SnapshotNow. > > Indeed, I'm thinking I don't believe in SnapshotSelf anymore either. > It's got all the same consistency issues as SnapshotNow. In fact, it > has *more* issues, because it's also vulnerable to weirdnesses caused by > inconsistent ordering of tuple updates among multiple tuples updated by > the same command. > > Why not tell people to use SnapshotDirty if they need a > not-guaranteed-consistent result? At least then it's pretty obvious > that you're getting some randomness in with your news.
You know, I didn't really consider that before, but I kind of like it. I think that would be entirely suitable (and perhaps better) for pgstattuple and get_actual_variable_range(). On further reflection, I think perhaps pgrowlocks should just register a fresh MVCC snapshot and use that. Using SnapshotDirty would return TIDs of unseen tuples, which does not seem to be what is wanted there. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers