On 2013-07-19 01:27:41 -0400, Tom Lane 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.
I don't think there are many people that aren't active on -hackers that
can actually understand the implications of using SnapshotNow. Given
-hackers hasn't fully grasped them in several cases... And even if those
borderline cases are safe, that's really only valid for a specific
postgres version. Catering to that doesn't seem like a good idea to me.
> 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.
Hm. I kind of can see the point of it in constraint code where it
probably would be rather hard to remove usage of it, but e.g. the
sepgsql usage looks pretty dubious to me.
At least in the cases where the constraint code uses them I don't think
the SnapshotNow dangers apply since those specific rows should be locked
et al.
The selinux usage looks like a design flaw to me, but I don't really
understand that code, so I very well may be wrong.
> 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.
Especially if we're going to lower the lock level of some commands, but
even now, that opens us to more issues due to nonmatching table
definitions et al. That doesn't sound like a good idea to me.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
