Re: On conflict update & hint bits - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: On conflict update & hint bits
Date
Msg-id CAM3SWZQXH4m-CQKsLeP-JeFuezMECJPTJc78EzHY0Z+kwevtLw@mail.gmail.com
Whole thread Raw
In response to On conflict update & hint bits  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Responses Re: On conflict update & hint bits  (Peter Geoghegan <pg@heroku.com>)
Re: On conflict update & hint bits  (Peter Geoghegan <pg@heroku.com>)
List 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 by date:

Previous
From: Michael Paquier
Date:
Subject: Re: PoC: Make it possible to disallow WHERE-less UPDATE and DELETE
Next
From: Michael Paquier
Date:
Subject: Re: COPY command with RLS bug