Postgres Pro
Downloads
Home   >   mailing lists

Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data - Mailing list pgsql-bugs

From Andrey Borodin
Subject Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Date
Msg-id DBD361BB-4327-4143-A849-36A262B22CEE@yandex-team.ru
Whole thread Raw
In response to Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-bugs
Tree view 

> 6 авг. 2021 г., в 23:03, Andrey Borodin <x4mmm@yandex-team.ru> написал(а):
>
> But how to get why something did not happen?
> During GetLockConflicts() proclocks SHMQueue do not include locks of concurrently running xid within
PrepareTransaction()[seems like it's with PostPrepare_locks(), but I'm not sure]. 
> The problem is reproducible within 1 second by the script leading to amcheck-detected corruption.

Ok, finally I've figured out this charade.

AtPrepare_Locks() transfers fast-path locks to normal locks pointing to PGPROC with xid in a process of conversion to
2PC.
ProcArrayClearTransaction(MyProc) resets xid int PGROCs.
GetLockConflicts() sees empty xid and vxid.
PostPrepare_Locks(xid) hids things with new PGPROC for 2PC.

PFA PoC fix. But I'm entirely not sure it's OK to do reorder things at PrepareTransaction() this way.

Thanks!

Best regards, Andrey Borodin.
Attachment

pgsql-bugs by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: BUG #17136: set shared_preload_libraries = 'pg_stat_statements,pg_prewarm,pg_trgm' , postgresql Cannot Startup
Next
From: Andrey Borodin
Date:
Subject: Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data