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

From: Dmitry Dolgov <9erthalion6(at)gmail(dot)com>
To: Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Routed ON CONFLICT inserts broken by partition-local deferrable unique constraints in 19 and master
Date: 2026-09-16 20:56:35
Message-ID: aqsArQmqLrDOo02Z@ddolgov-thinkpadt14sgen1.rmtde.csb
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Tue, Sep 01, 2026 at 11:15:09AM +0200, Mihail Nikalayeu wrote:
> > 2bc7e886fc1 and the commit that has triggered this thread both refer
> > to the same set of improvements regarding the interactions of rebuilt
> > indexes and ON CONFLICT, so my take is that if we finish by updating
> > the same area of the code we could just group both changes together,
> > but I agree that my line of thoughts may be thin. It seems to me that
> > we'd better look first at this secondary issue before drawing a
> > conclusion regarding if both issues should be handled together or
> > separately.
>
> This is a "grouped" version. Also, it handles possible collation
> issues + provides a set of tests to pin the correct behaviour.

+/*
+ * IsIndexCompatibleAsArbiter
+ * Return true if two indexes of the same table are interchangeable as
+ * speculative insertion arbiters for INSERT ON CONFLICT.
+ *
+ * To be interchangeable, the two indexes must agree on which tuples conflict,

[...]

+ /* 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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-09-16 21:01:38 Re: [PATCH] Release replication slot on error in SQL-callable slot functions
Previous Message Andrey Rachitskiy 2026-09-16 20:54:31 [PATCH] Catch croak during PL/Perl result conversion