Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
От | Andres Freund |
---|---|
Тема | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Дата | |
Msg-id | 20131011170256.GA4056218@alap2.anarazel.de обсуждение исходный текст |
Ответ на | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: