Horton
Menu

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

Noah Misch <noah@leadboat.com>

View thread
From: Noah Misch <noah@leadboat.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-bugs@lists.postgresql.org
Date: 2021-07-17T20:12:40Z
Lists: pgsql-bugs 
On Sat, Jul 17, 2021 at 10:01:00PM +0500, Andrey Borodin wrote:
> Sorry to say that, but $subj persists. Here's a simple reproduction.

> The problem is WaitForLockersMultiple() gathers running vxids and 2pc xids. Then it waits, but if vxid is converted to 2pc it fails to wait.

That makes sense.

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

Suppose some transaction has a vxid but no xid.  Shortly after
GetLockConflicts(), it acquires an xid, modifies the table, and issues PREPARE
TRANSACTION.  Could that cause a corrupt index even with this diff?

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Improve contrib/amcheck's tests for CREATE INDEX CONCURRENTLY.

  2. Fix minor memory leaks in pg_dump.

  3. Avoid race in RelationBuildDesc() affecting CREATE INDEX CONCURRENTLY.

  4. Fix CREATE INDEX CONCURRENTLY for the newest prepared transactions.

  5. Add -w back to the flags for pg_ctl (re)start in PostgresNode

  6. Fix CREATE INDEX CONCURRENTLY for simultaneous prepared transactions.