Routed ON CONFLICT inserts broken by partition-local deferrable unique constraints in 19 and master

[pg-hub-mirror]

Read-only mirror. Reply and review on pgsql-hackers; activity here is not sent upstream.

• Original author: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
• Mailing list: pgsql-hackers
• Message-ID: aqwnMDPBLBQ64Eus@alvherre.pgsql
• Original email

Patch files:

• 0001-Tighten-definition-of-ON-CONFLICT-arbiter-index-equi.patch

---

On 2026-Sep-01, Zsolt Parragi wrote:

On Tue, 01 Sep 2026, Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com> wrote:

This is a "grouped" version. Also, it handles possible collation
issues + provides a set of tests to pin the correct behaviour.

Thanks, this looks better what I had in mind, I would have missed a
few corner cases this patch covers.
I spent some time with this and ended up with the attached. I don't I
found anything to change, apart from minor edits to the commit message.
I'll probably edit it some more before push, to mention the change of
list_difference() to equal().
The non-deterministic collation aspect mentioned in an XXX comment added
by the patch was a bug in 18 and back, and continues to be a bug after
this patch. That's shown with the following test case:
CREATE COLLATION ci (provider = icu, locale = 'und-u-ks-level2', deterministic = false);
-- First part of test case: ON CONFLICT listing a column works fine.
CREATE TABLE t (x text, y text);
ALTER TABLE t ADD CONSTRAINT t_x_key UNIQUE (x);
CREATE UNIQUE INDEX t_x_ci ON t (x COLLATE ci);
INSERT INTO t VALUES ('a', 'first');
INSERT INTO t VALUES ('A', 'second') ON CONFLICT (x) DO UPDATE SET y = excluded.y;
-- the end result here is ('a', 'second'), showing that ON CONFLICT worked.
SELECT x, y FROM t;
-- repeat, but use ON CONFLICT ON CONSTRAINT. Throws error but shouldn't.
INSERT INTO t VALUES ('A', 'third') ON CONFLICT ON CONSTRAINT t_x_key DO UPDATE SET y = excluded.y;
It's not on this patch to solve this problem, as it's not a new problem.
But we should consider a backpatchable fix at some point.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"I can't go to a restaurant and order food because I keep looking at the
fonts on the menu. Five minutes later I realize that it's also talking
about food" (Donald Knuth)

[pg-hub-mirror]

Earlier design discussion: Discussion #377

[pg-hub-mirror]

Álvaro Herrera <alvherre(at)kurilemu(dot)de> via pgsql-hackers · original email

Pushed, thanks.

Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
Syntax error: function hell() needs an argument.
Please choose what hell you want to involve.

[pg-hub-mirror]

Álvaro Herrera <alvherre(at)kurilemu(dot)de> via pgsql-hackers · original email

On 2026-Sep-16, Dmitry Dolgov wrote:

• /* number of key attributes must match */
• if (indexForm1->indnkeyatts != indexForm2->indnkeyatts)

• return false;
  

I see that it was like this in the original commit, but isn't it too
restrictive regarding the goal stated in the function comment? If say
there are two unique indexes on columns (a), and (a, b), they have the
same understanding of what tuples will conflict, but the latter one will
not be used as an arbiter index. To be fair, I don't see how this may
become problem in practice, but still.
I'm not sure I understand this concern. Do you want to elaborate?
This functionality is there to support having two copies of "the same"
index during REINDEX CONCURRENTLY, and of course the second copy is
going to be identical in definition to the first one.
Maybe you want to propose a different name or a different comment for
this new function?
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/

[pg-hub-mirror]

Dmitry Dolgov <9erthalion6(at)gmail(dot)com> via pgsql-hackers · original email

On Fri, Sep 18, 2026 at 01:54:46PM +0200, Álvaro Herrera wrote:
On 2026-Sep-16, Dmitry Dolgov wrote:

• /* number of key attributes must match */
• if (indexForm1->indnkeyatts != indexForm2->indnkeyatts)

•   return false;
  

I see that it was like this in the original commit, but isn't it too
restrictive regarding the goal stated in the function comment? If say
there are two unique indexes on columns (a), and (a, b), they have the
same understanding of what tuples will conflict, but the latter one will
not be used as an arbiter index. To be fair, I don't see how this may
become problem in practice, but still.

I'm not sure I understand this concern. Do you want to elaborate?

This functionality is there to support having two copies of "the same"
index during REINDEX CONCURRENTLY, and of course the second copy is
going to be identical in definition to the first one.

Maybe you want to propose a different name or a different comment for
this new function?
Yes, I get that. But the way how comment is written seems to emphasize
interchangeability of indexes in general, mentioning REINDEX
CONCURRENTLY as one use case, but not necessarily the only one -- or at
least it's my reading of it. Maybe a better commentary can solve it, but
since it's already pushed, consider it to be an optional nit pick.

[pg-hub-mirror]

Álvaro Herrera <alvherre(at)kurilemu(dot)de> via pgsql-hackers · original email

On 2026-Sep-18, Dmitry Dolgov wrote:

Yes, I get that. But the way how comment is written seems to emphasize
interchangeability of indexes in general, mentioning REINDEX
CONCURRENTLY as one use case, but not necessarily the only one -- or at
least it's my reading of it. Maybe a better commentary can solve it, but
since it's already pushed, consider it to be an optional nit pick.
I'll gladly take your nit pick.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
really, I see PHP as like a strange amalgamation of C, Perl, Shell
inflex: you know that "amalgam" means "mixture with mercury",
more or less, right?
i.e., "deadly poison"