Re: Confirmation on concurrent SELECT FOR UPDATE with ON CONFLICT DO NOTHING

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Matt Magoffin <postgresql(dot)org(at)msqr(dot)us>
Cc: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Confirmation on concurrent SELECT FOR UPDATE with ON CONFLICT DO NOTHING
Date: 2026-04-30 19:35:43
Message-ID: 83819e975523be4d320141ff1363dfb40c82289b.camel@cybertec.at
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, 2026-05-01 at 07:07 +1200, Matt Magoffin wrote:
> > On 30 Apr 2026, at 6:42 PM, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
> >
> > So I'd say that the documentation is not quite accurate.  Really, the DELETE does not place
> > a row lock on the row.
> >
> > That must account for the behavior difference: after the SELECT ... FOR UPDATE, the
> > INSERT ... ON CONFLICT interprets the row lock as a conflict and moves on, while in the
> > DELETE case it sees no conflict (yet), but has to wait for the transaction to complete before
> > it knows how to proceed.
> >
> > I cannot say if that is intentional; as I said initially, I am surprised too.
>
> Thank you for your additional insights, Laurenz.

Also, the behavior difference only occurs with ON CONFLICT DO NOTHING.
If you use ON CONFLICT ... DO UPDATE ..., the update will block.
That makes the behavior difference somewhat less bad in my eyes.

Yours,
Laurenz Albe

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Masahiko Sawada 2026-04-30 20:40:47 Re: Support logical replication of DDLs, take2
Previous Message Matt Magoffin 2026-04-30 19:07:30 Re: Confirmation on concurrent SELECT FOR UPDATE with ON CONFLICT DO NOTHING