Horton

Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

Álvaro Herrera <alvherre@kurilemu.de>

View thread
From: Álvaro Herrera <alvherre@kurilemu.de>
To: Mihail Nikalayeu <mihailnikalayeu@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Noah Misch <noah@leadboat.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2025-12-12T10:17:30Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Replace flaky CIC/RI isolation tests with a TAP test

  2. Disable recently added CIC/RI isolation tests

  3. Fix infer_arbiter_index for partitioned tables

  4. Stabilize tests some more

  5. Put back alternative-output expected files

  6. Remove doc and code comments about ON CONFLICT deficiencies

  7. Avoid use of NOTICE to wait for snapshot invalidation

  8. Fix ON CONFLICT with REINDEX CONCURRENTLY and partitions

  9. Fix ON CONFLICT ON CONSTRAINT during REINDEX CONCURRENTLY

  10. Fix new test for CATCACHE_FORCE_RELEASE builds

  11. Improve test case stability

  12. Fix infer_arbiter_index during concurrent index operations

  13. Doc: cover index CONCURRENTLY causing errors in INSERT ... ON CONFLICT.

  14. Fix infer_arbiter_indexes() to not assume resultRelation is 1.

  15. Revert temporal primary keys and foreign keys

On 2025-Dec-12, Mihail Nikalayeu wrote:

> Hello, Álvaro!
> 
> On Thu, Dec 11, 2025 at 10:36 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:
> > I just saw a failure in CI for an unrelated patch
> 
> I'll try to dive deeper tomorrow to find a fix, but it feels like we
> are doing something wrong here.

Hmm, this is a good point.

> But currently we are just trying (not the first time already) to make
> sure OUTPUT of the test is EXACTLY equal to some variant.

A low-cost option might be to add alternative expected file(s), which
matches other variant(s).  I think trying to make isolationtester "smart
match" the output might be more complicated than is warranted.

> I am afraid amount of time needed to stabilize such test (in its
> output, not the sense) is not cover potential value of it.

Yeah, could be.

> Also, I imaging someone changing something unrelated (catalog snapshot
> invalidation, for example) and test starts to fail on some rear animal
> once a week.... Ughn.

Another idea might be to rewrite these tests using BackgroundPsql under
the TAP infrastructure.  That's quite a bit more tedious to write, but
we can be more precise on detecting whether some particular error
message was thrown or not.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"How amazing is that? I call it a night and come back to find that a bug has
been identified and patched while I sleep."                (Robert Davidson)
               http://archives.postgresql.org/pgsql-sql/2006-03/msg00378.php