Re: BUG #18279: Duplicate key violation and Deadlock when using ON CONFLICT/DO UPDATE with multiple unique indexes

From: 노영은 <nye7181(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18279: Duplicate key violation and Deadlock when using ON CONFLICT/DO UPDATE with multiple unique indexes
Date: 2024-01-11 08:24:31
Message-ID: CALQG0cTfnKArBha1YDcqWXi+boF26RPP-EwZpvXTc8-V-6uPGA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thanks for the answer.

If the primary key was inferred as the arbiter index, shouldn't it be
UPDATE because the arbiter index was conflicted?
And when parallelism is low, the duplicate violations don't occur.

When I ran ON CONFLICT (user_id, date) DO UPDATE as you suggested, a
duplicate violation on primary key occurred.
However, the deadlock seems to disappear.
```
ERROR: duplicate key value violates unique constraint "email_stats_pkey"
DETAIL: Key (id)=(2024-01-01_1) already exists.
```

2024년 1월 11일 (목) 오전 12:12, Peter Geoghegan <pg(at)bowt(dot)ie>님이 작성:

> On Wed, Jan 10, 2024 at 4:28 AM PG Bug reporting form
> <noreply(at)postgresql(dot)org> wrote:
> > I have a table with a primary key and a unique index.
> > First, I ran an INSERT query and then several INSERT INTO ON CONFLICT DO
> > UPDATE queries in parallel.
> > This will almost always result in Duplicate key violations, and sometimes
> > Deadlocks.
> > When I removed the unique index, there was no Duplicate key violation or
> > Deadlock.
>
> This is not a bug. The statements you've shown use "ON CONFLICT (id)
> DO UPDATE", which will make the primary key the arbiter index -- the
> index used for upserting. The duplicate violation errors relate to the
> unique index, though.
>
> In general the implementation only uses one arbiter index to decide
> whether to insert or to update each row (barring certain edge cases
> where the table has multiple equivalent/redundant unique indexes).
> It's possible that you'll get the behavior you expect by specifying
> "ON CONFLICT (user_id, date) DO UPDATE" instead -- though I can't be
> sure of that.
>
> --
> Peter Geoghegan
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Richard Guo 2024-01-11 09:08:30 Re: BUG #18260: Unexpected error: "negative bitmapset member not allowed" triggered by multiple JOIN
Previous Message PG Bug reporting form 2024-01-11 06:47:43 BUG #18283: vacuum full use a large amount of memory (may cause OOM)