Re: Conflict detection for multiple_unique_conflicts in logical replication

From: Peter Smith <smithpb2250(at)gmail(dot)com>
To: Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>
Subject: Re: Conflict detection for multiple_unique_conflicts in logical replication
Date: 2025-04-04 05:11:09
Message-ID: CAHut+PvFdHOor1oqb+8nWfaeTPnWQcv0YttcUp3_=4p2nOEQ4w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Nisha,

I saw this patch was already pushed [1], but there was one thing I
never quite understood about this feature, and I didn't find the
answer in the thread posts above.

My question: Why is there only a single new conflict type being added here?

e.g.

Conflict due to INSERT
- single conflict ==> 'insert_exists'
- multiple conflicts ==> 'multiple_unique_conflicts'

Conflict due to UPDATE
- single conflict ==> 'update_exists'
- multiple conflicts ==> 'multiple_unique_conflicts'

My point is, if it is deemed useful for a user to know if a *single*
conflict was caused by an INSERT or by an UPDATE, then why is it not
equally useful to know if *multiple* conflicts were caused by an
INSERT or by an UPDATE?

In other words, instead of just 'multiple_unique_conflicts', why
wasn't this new conflict type split into two, something like
'insert_multiple_conflicts' and 'update_multiple_conflicts'?

======
[1] https://github.com/postgres/postgres/commit/73eba5004a06a744b6b8570e42432b9e9f75997b

Kind Regards,
Peter Smith.
Fujitsu Australia

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Hayato Kuroda (Fujitsu) 2025-04-04 05:33:56 RE: Some codes refer slot()->{'slot_name'} but it is not defined
Previous Message Sergey Tatarintsev 2025-04-04 05:06:49 Re: Restrict publishing of partitioned table with a foreign table as partition