Re: On conflict update & hint bits
От | Peter Geoghegan |
---|---|
Тема | Re: On conflict update & hint bits |
Дата | |
Msg-id | CAM3SWZQXH4m-CQKsLeP-JeFuezMECJPTJc78EzHY0Z+kwevtLw@mail.gmail.com обсуждение исходный текст |
Ответ на | On conflict update & hint bits (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>) |
Ответы |
Re: On conflict update & hint bits
Re: On conflict update & hint bits |
Список | pgsql-hackers |
On Fri, Sep 30, 2016 at 5:33 PM, Konstantin Knizhnik <k.knizhnik@postgrespro.ru> wrote: > So the question is whether it is correct that ExecOnConflictUpdate tries to > access and update tuple without holding lock on the buffer? You're right -- this is a bug in Postgres. I'm travelling from Ireland to the USA this weekend, but will work on this early next week. I don't think it's a particularly tricky fix -- as you say, it is necessary to have at least a shared buffer lock to call HeapTupleSatisfiesVisibility(), and we quite simply fail to ensure that. We must have a shared buffer lock in the visibility-check path for ON CONFLICT DO UPDATE where isolation level > READ COMMITTED -- a buffer pin is not enough. It also looks like the DO NOTHING variant is similarly affected, even when the isolation level is READ COMMITTED. :-( Thanks for the detailed report. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: