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

From: Matt Magoffin <postgresql(dot)org(at)msqr(dot)us>
To: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
Cc: 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 02:48:32
Message-ID: 8BCF50C4-D36B-4453-9B09-AA717AE6F563@msqr.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general


> On 30 Apr 2026, at 11:37 AM, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> wrote:
>
> So in your first case the INSERT is never done and there is no lock for the INSERT in any case.

Thanks for the info, Adrian. And so for my 2nd case, where the INSERT is blocked by the DELETE statement, I see the docs say

The FOR UPDATE lock mode is also acquired by any DELETE on a row…

But I am not finding the info that talks about why the INSERT … ON CONFLICT DO NOTHING does block until the DELETE finishes. I guess in my mind the SELECT … FOR UPDATE and DELETE were acquiring the same kind of row lock, so the behaviour of the INSERT would be the same across both cases.

I suppose what I’d be keen to confirm is that the blocking behaviour I get with the DELETE is expected behaviour, that I can count on. Do you know if that is true?

Cheers,
Matt

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Ron Johnson 2026-04-30 03:39:03 Re: Issue during partition drop
Previous Message veem v 2026-04-30 02:37:21 Issue during partition drop