Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Cc: Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY
Date: 2025-11-24 22:15:19
Message-ID: aSTY9z_b4PzZNSap@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 24, 2025 at 06:49:47PM +0100, Alvaro Herrera wrote:
> This patch would bring the committed test file up to date with what you
> last submitted. However, I didn't understand what is the problem with
> the original formulation, and I haven't seen the test fail ... can you
> explain?

Reading through bc32a12e0db2, I am puzzled by the committed result
here:
+#ifdef USE_INJECTION_POINTS
+ if (conflict)
+ INJECTION_POINT("check-exclusion-or-unique-constraint-conflict", NULL);
+ else
+ INJECTION_POINT("check-exclusion-or-unique-constraint-no-conflict", NULL);
+#endif

The "no-conflict" point is used in the isolation test, but not the
other in the "conflict == true" path:
$ git grep check-exclusion-or-unique-constraint-conflict
src/backend/executor/execIndexing.c:
INJECTION_POINT("check-exclusion-or-unique-constraint-conflict", NULL);

If you have no plans for it in the long-term, I'd rather remove it
from the tree, rather than keep it. Of course, I would keep the
USE_INJECTION_POINTS block to avoid the extra boolean check in
non-USE_INJECTION_POINTS builds.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Mihail Nikalayeu 2025-11-24 22:24:00 Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY
Previous Message Peter Geoghegan 2025-11-24 22:09:05 Re: Patch: VACUUM should ignore (CREATE |RE)INDEX CONCURRENTLY for xmin horizon calculations