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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
