From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: On conflict update & hint bits |
Date: | 2016-10-01 12:15:05 |
Message-ID: | CAM3SWZQXH4m-CQKsLeP-JeFuezMECJPTJc78EzHY0Z+kwevtLw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 30, 2016 at 5:33 PM, Konstantin Knizhnik
<k(dot)knizhnik(at)postgrespro(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-10-01 12:41:17 | Re: COPY command with RLS bug |
Previous Message | Michael Paquier | 2016-10-01 11:19:06 | Re: PoC: Make it possible to disallow WHERE-less UPDATE and DELETE |