From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)bowt(dot)ie> |
Subject: | Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data |
Date: | 2021-08-22 12:30:47 |
Message-ID: | 4A911574-5F35-4AED-BD88-8214C081CF71@yandex-team.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Andres, Noah, thanks for the review.
> 16 авг. 2021 г., в 10:13, Noah Misch <noah(at)leadboat(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2021-08-22 17:42:01 | Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data |
Previous Message | Gerard H. Pille | 2021-08-21 13:15:07 | pg_basebackup behavior on non-existent slot |