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

From: Matt Magoffin <postgresql(dot)org(at)msqr(dot)us>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
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:07:30
Message-ID: 93ADF4E5-CF49-4347-8A79-33655A8E0299@msqr.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general


> 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.

Kind regards,
Matt

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Laurenz Albe 2026-04-30 19:35:43 Re: Confirmation on concurrent SELECT FOR UPDATE with ON CONFLICT DO NOTHING
Previous Message Hannu Krosing 2026-04-30 14:02:56 Re: Support logical replication of DDLs, take2