Robert Haas <robertmhaas@gmail.com> writes:
> So we have to take the snapshot before you begin execution, but it
> seems that to avoid surprising behavior we also have to take it after
> acquiring locks. And it looks like locking is intertwined with a
> bunch of other parse analysis tasks that might require a snapshot to
> have been taken first. Whee.
Yeah. I think that a good solution to this would involve guaranteeing
that the execution snapshot is not taken until we have all locks that
are going to be taken on the tables. Which is likely to involve a fair
amount of refactoring, though I admit I've not looked at details.
In any case, it's a mistake to think about this in isolation. If we're
going to do something about redefining SnapshotNow to avoid its race
conditions, that's going to move the goalposts quite a lot.
Anyway, my feeling about it is that I don't want 9.2 to have an
intermediate behavior between the historical one and whatever we end up
designing to satisfy these concerns. That's why I'm pressing for
reversion and not a band-aid fix in 9.2. I certainly hope we can do
better going forward, but this is not looking like whatever we come up
with would be sane to back-patch.
regards, tom lane