On 2013-10-11 08:43:43 -0400, Robert Haas wrote:
> > I appreciate that it's odd that serializable transactions now have to
> > worry about seeing something they shouldn't have seen (when they
> > conclusively have to go lock a row version not current to their
> > snapshot).
>
> Surely that's never going to be acceptable. At read committed,
> locking a version not current to the snapshot might be acceptable if
> we hold our nose, but at any higher level I think we have to fail with
> a serialization complaint.
I think an UPSERTish action in RR/SERIALIZABLE that notices a concurrent
update should and has to *ALWAYS* raise a serialization
failure. Anything else will cause violations of the given guarantees.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
