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-19T00:30:09Z
Lists: pgsql-bugs 
On Sun, Jul 18, 2021 at 10:17:28AM +0500, Andrey Borodin wrote:
> > 18 июля 2021 г., в 01:12, Noah Misch <noah@leadboat.com> написал(а):
> > 
> > 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?
> 
> Firstly I've tried to stress things out. This little go program [0] easily reproduces corruption on patched code.

By "patched code", you mean return_xids_with_vxids.diff applied to recent
master, right?

> Meanwhile vxid->xid->2px program does not [1] (both patched and unpatched).
> 
> I think CIC does not care much about VXIDs at all. It's only important when real XID started: before GetLockConflicts() or after.

CIC likes VXIDs because they're assigned early in the xact, before any catalog
access.  Consider the DefineIndex() step "wait until no running transaction
could have the table open with the old list of indexes."  ExecOpenIndices()
can happen before AssignTransactionId(), so waiting on XIDs alone wouldn't
suffice.

To fix $SUBJECT, it sounds like we need a way to identify a transaction,
usable as early as the transaction's first catalog access and remaining valid
until COMMIT PREPARED finishes.  We may initially see a transaction as having
a VXID and no XID, then later need to wait for that transaction when it has
entered prepared state, having an XID and no VXID.  How might we achieve that?

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.