Re: Confirmation on concurrent SELECT FOR UPDATE with ON CONFLICT DO NOTHING
| От | Laurenz Albe |
|---|---|
| Тема | Re: Confirmation on concurrent SELECT FOR UPDATE with ON CONFLICT DO NOTHING |
| Дата | |
| Msg-id | 83819e975523be4d320141ff1363dfb40c82289b.camel@cybertec.at обсуждение |
| Ответ на | Re: Confirmation on concurrent SELECT FOR UPDATE with ON CONFLICT DO NOTHING (Matt Magoffin <postgresql.org@msqr.us>) |
| Список | 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.albe@cybertec.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
В списке pgsql-general по дате отправления: