On Fri, Jul 19, 2013 at 1:27 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Noah Misch <noah@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