[Álvaro Herrera <alvherre@kurilemu.de>]

Hi,

I just saw a failure in CI for an unrelated patch,

https://api.cirrus-ci.com/v1/artifact/task/4641105595072512/testrun/build/testrun/injection_points/i...

inline patch 1: /home/postgres/postgres/build/testrun/injection_points/isolation/results/reindex-concurrently-upsert.out (+3/-12 lines) download inline-1.patchdiff -U3 /home/postgres/postgres/src/test/modules/injection_points/expected/reindex-concurrently-upsert.out /home/postgres/postgres/build/testrun/injection_points/isolation/results/reindex-concurrently-upsert.out
--- /home/postgres/postgres/src/test/modules/injection_points/expected/reindex-concurrently-upsert.out	2025-12-11 12:41:23.982167232 +0000
+++ /home/postgres/postgres/build/testrun/injection_points/isolation/results/reindex-concurrently-upsert.out	2025-12-11 12:45:24.038078804 +0000
@@ -62,22 +62,13 @@
 (1 row)
 
 step s1_start_upsert: <... completed>
+step s2_start_upsert: <... completed>
+step s3_start_reindex: <... completed>
 step s4_wakeup_s2: 
 	SELECT injection_points_detach('exec-insert-before-insert-speculative');
 	SELECT injection_points_wakeup('exec-insert-before-insert-speculative');
 
-injection_points_detach
------------------------
-                       
-(1 row)
-
-injection_points_wakeup
------------------------
-                       
-(1 row)
-
-step s2_start_upsert: <... completed>
-step s3_start_reindex: <... completed>
+ERROR:  could not detach injection point "exec-insert-before-insert-speculative"
 
 starting permutation: s3_setup_wait_before_swap s3_start_reindex s1_start_upsert s4_wakeup_to_swap s2_start_upsert s4_wakeup_s2 s4_wakeup_s1
 injection_points_attach


I haven't seen anywhere else.  I don't believe this to be a problem in
the patch, because the patch is about partitions and this test case does
not involve partitioned tables -- so I'm inclined to think it's a timing
issue in the test itself.  If so, this can probably be fixed with
additional constraints on on of the steps in the permutation ...
probably maybe s2_start_upsert depend on s4_wakeup_s2?  But since I
can't easily reproduce this, I have no idea if this is a valid
solution.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/