Horton
Menu

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

Andrey Borodin <x4mmm@yandex-team.ru>

View thread
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Noah Misch <noah@leadboat.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>, Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@bowt.ie>
Date: 2021-08-22T12:30:47Z
Lists: pgsql-bugs 
Andres, Noah, thanks for the review.

> 16 авг. 2021 г., в 10:13, Noah Misch <noah@leadboat.com> написал(а):
> 
> With v12, on my machine, the same loop took 2000s to get three failures, both
> of which were in the 1PC tests.  I ran out of time to study the failure
> mechanism.  Would you diagnose what happens when it fails on your server?
I'm still in progress of investigation. With your fix for RelationBuildDesc() invals my reproduction is also quite slow - I get error within 10 minutes or so.

I've observed few times that same Xid was WaitXact()'es twice. Is it possible that taking ShareLock on running xid (taken from PGPGROC of vxid) is not a good way to wait for transaction completition?
Is it possible that xid is in PGPROC before backend acquires its own lock on xid?


> Also see the larger review from Andres.

Sure, I will address Andres's notes as long as patches will finally work without errors. I agree with the idea of not inventing dynamic list and other pointed problems.

Best regards, Andrey Borodin.

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.