On 2013-07-26 09:50:32 -0400, Robert Haas wrote:
> sepgsql is using SnapshotSelf to find the old version of a tuple that
> was updated by the core code just before. That should be safe in the
> sense that there can't be a currently-committing transaction somewhere
> else that's updated that tuple, if we know that our own uncommitted
> transaction has done a transactional update. There was a recent
> thread discussing whether another API might be better, and I'd be
> prepared to concede that it might be. But I don't think it's
> drop-dead broken.
It's safe for the tuples updated in that transaction, but it's not safe
to look at anything else if you expect results without the SnapshotNow
problems. E.g. looking at a newly created attribute is fine, but
iterating over all attributes not necessarily.
I am more concerned about the care needed when placing
CommandCounterIncrement()'s somewhere though. It seems more than likely
that this will get repeatedly broken, even if it's not atm (which I
doubt). E.g. inheritance handling seems to be rather wonky WRT this.
> Not that I really object if someone wants to have a go at getting rid
> of SnapshotSelf, but I think it'd be worth articulating what we hope
> to accomplish by so doing.
Agreed. From the internal usages there doesn't seem to be too much
pressure.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
