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