Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY

Mikhail Nikalayeu <mihailnikalayeu@gmail.com>

From: Mihail Nikalayeu <mihailnikalayeu@gmail.com>

To: Álvaro Herrera <alvherre@kurilemu.de>

Cc: Michael Paquier <michael@paquier.xyz>, Noah Misch <noah@leadboat.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>

Date: 2025-12-13T17:00:00Z

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 →

Replace flaky CIC/RI isolation tests with a TAP test
- e1c971945d62 19 (unreleased) landed
Disable recently added CIC/RI isolation tests
- 77038d6d0b49 19 (unreleased) landed
Fix infer_arbiter_index for partitioned tables
- 81f72115cf18 19 (unreleased) landed
Stabilize tests some more
- a4a0fa0c7587 19 (unreleased) landed
Put back alternative-output expected files
- be25c7767728 19 (unreleased) landed
Remove doc and code comments about ON CONFLICT deficiencies
- 758479213d57 19 (unreleased) landed
Avoid use of NOTICE to wait for snapshot invalidation
- 5dee7a603f66 19 (unreleased) landed
Fix ON CONFLICT with REINDEX CONCURRENTLY and partitions
- 90eae926abbb 19 (unreleased) landed
Fix ON CONFLICT ON CONSTRAINT during REINDEX CONCURRENTLY
- 2bc7e886fc1b 19 (unreleased) landed
Fix new test for CATCACHE_FORCE_RELEASE builds
- 9e8fa05d3412 19 (unreleased) landed
Improve test case stability
- 417ac9c1eeeb 19 (unreleased) landed
Fix infer_arbiter_index during concurrent index operations
- bc32a12e0db2 19 (unreleased) landed
Doc: cover index CONCURRENTLY causing errors in INSERT ... ON CONFLICT.
- 438ccd33a37a 13.23 landed
- faba2595d619 14.20 landed
- e1dd1f924e19 15.15 landed
- 4c2895629f6f 16.11 landed
- 46524d519a2d 18.1 landed
- 27f714b5dad7 17.7 landed
- 8b18ed6dfbb8 19 (unreleased) landed
Fix infer_arbiter_indexes() to not assume resultRelation is 1.
- 915de706d28c 17.0 cited
Revert temporal primary keys and foreign keys
- 8aee330af55d 17.0 cited

 Hello, Álvaro!

On Fri, Dec 12, 2025 at 11:17 AM Álvaro Herrera <alvherre@kurilemu.de> wrote:
> 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.

I think I understood the race, currently thinking about two possible approaches:

1) extract LOOP waiting for injection point into some function like
"injection_points_await_waiter" and add it almost between each steps
to ensure it all executed by guardrails (effectively reducing
concurrency instead of making isolationtester to report data the same
way)
2) rewrite using TAP infra

What do you think about this? Which one do you prefer?

Best regards,
Mikhail.