| 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-05-04 19:53:39 |
| Message-ID: | 0B23DB17-EB6B-4B56-9A61-D7A35A039DA2@msqr.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
> On 1 May 2026, at 7:35 AM, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>
> 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.
Yes, I had noticed that as well. In my case my goal is to both block and “do nothing” if after blocking a matching row is found. If this behaviour isn’t expected, I thought I could change to
ON CONFLICT DO UPDATE SET id = EXCLUDED.id
to essentially “do nothing” but I thought I would incur an actual update and I wanted to avoid the churn I presumed that would include.
Kind regards,
Matt
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Laurenz Albe | 2026-05-04 20:45:16 | Re: Choosing default collation/ctype |
| Previous Message | Daniel Verite | 2026-05-04 19:34:00 | Re: Choosing default collation/ctype |