Re: On conflict update & hint bits
От | Peter Geoghegan |
---|---|
Тема | Re: On conflict update & hint bits |
Дата | |
Msg-id | CAM3SWZR6AN++h24e6y2NWETjMTCjXDbFgEifOss2jpfPEmqCdw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: On conflict update & hint bits (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: On conflict update & hint bits
|
Список | pgsql-hackers |
On Sat, Oct 1, 2016 at 5:15 AM, Peter Geoghegan <pg@heroku.com> wrote: > 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. (Thomas Munro and Kevin Grittner added to CC list.) Attached is a revision of Thomas' patch to fix a related issue; it now also fixes this no-buffer-lock-held issue. He posted his version of this to a -general mailing list thread a week ago [1]. This was a thread about spurious serialization failure with ON CONFLICT DO NOTHING. I understand that Kevin is still not happy with the behavior under SSI even with our fix, since serialization failures will still occur more often than necessary (see other thread for details of what I'm talking about). I believe this patch to be a strict improvement on master, and I suggest it be applied in advance of the deadline to get fixes in for the next set of point releases. Note that this revision includes Thomas' isolation test, which is completely unchanged. I still intend to work with Kevin to do better than this under SSI, though that will probably be for a future point release. The behavior proposed by my fix here is the right thing for REPEATABLE READ isolation level, which has nothing to do with Kevin's proposed more careful handling under SSI. Besides, the buffer pin bug reported by Konstantin on this thread really should be addressed ASAP. [1] https://www.postgresql.org/message-id/CAEepm=3Ra9NgDHocDBtB4iiB7MWdavQybNS3F47SvKh1Mk-mFQ@mail.gmail.com -- Peter Geoghegan
Вложения
В списке pgsql-hackers по дате отправления: