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