Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data

> 1 мая 2021 г., в 17:42, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> написал(а):
>
>
> FWIW I have 2 new reported cases on 12.6.

Sorry to say that, but $subj persists. Here's a simple reproduction.
To get corrupted index you need 3 psql sessions A, B and C. By default command is executed in A.

create extension amcheck ;
create table t1(i int);
create index on t1(i);

begin;
insert into t1 values(0);

-- session C: reindex table concurrently t1;

prepare transaction 'a';
begin;
insert into t1 values(0);
-- session B: commit prepared 'a';
prepare transaction 'b';
begin;
insert into t1 values(0);
-- session B: commit prepared 'b';
prepare transaction 'c';

begin;
insert into t1 values(0);
-- session B: commit prepared 'c';
prepare transaction 'd';
commit prepared 'd';

-- session C: postgres=# select bt_index_check('i1',true);
ERROR: heap tuple (0,2) from table "t1" lacks matching index tuple within index "i1"
HINT: Retrying verification using the function bt_index_parent_check() might provide a more specific error.

The problem is WaitForLockersMultiple() gathers running vxids and 2pc xids. Then it waits, but if vxid is converted to 2pc it fails to wait.
I could not compose isolation test for this, because we need to do "prepare transaction 'a';" only when "reindex table concurrently t1;" is already working for some time.

To fix it we can return locking xids along with vxids from GetLockConflicts() like in attached diff. But this approach seems ugly.

Best regards, Andrey Borodin.