Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY

> On 28 May 2022, at 12:02, Andres Freund <andres@anarazel.de> wrote:
>
> I think you basically need to force some, but not all, of the modifying
> transactions to be open for a bit longer, so that it's more likely that
> there's a chance to prune vs CIC waiting. Might also be helpful to update rows
> multiple times within an xact.
Now I've got 2 different versions of test for master branch. Both fail in 50% of cases on my machine. Both take
approximately4 seconds of wallclock time and 1 second of CPU time. 

v3: wait with a fraction of waiting transactions.
This test fails with
0   postgres                            0x00000001049ec508 ExceptionalCondition + 124
1   postgres                            0x00000001045ea284 heap_page_prune + 2992
2   postgres                            0x00000001045e9670 heap_page_prune_opt + 424
3   postgres                            0x00000001045e25c0 heapam_index_fetch_tuple + 140
4   postgres                            0x0000000100272d60 index_fetch_heap + 104
5   postgres                            0x0000000100272e18 index_getnext_slot + 88
6   postgres                            0x00000001003bbf4c check_exclusion_or_unique_constraint + 440
7   postgres                            0x00000001003bc360 ExecCheckIndexConstraints + 232
8   postgres                            0x00000001003ea30c ExecInsert + 1024
9   postgres                            0x00000001003e90cc ExecModifyTable + 1536
10  postgres                            0x00000001003bd0cc standard_ExecutorRun + 268
11  postgres                            0x0000000100542d94 ProcessQuery + 160
12  postgres                            0x00000001005423c8 PortalRunMulti + 396
13  postgres                            0x0000000100541cfc PortalRun + 476

And reverting d9d0762 does not fix the issue. I'm not sure if I'm observing some other problem here.

v4 of a test not use pg_sleep() and fails with regular amcheck failure. Reverting d9d0762 fixes the test. Unless I
executethe test for 1 million transactions, then it fail even with a revert... 

I suspect that v3 and v4 triggers different problems.

Best regards, Andrey Borodin.