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

From Andres Freund
Subject Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Date
Msg-id 20210829180913.ghojzzsgkqgm7vki@alap3.anarazel.de
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
Hi,

On 2021-08-29 12:27:31 +0500, Andrey Borodin wrote:
> > 15 авг. 2021 г., в 18:45, Andres Freund <andres@anarazel.de> написал(а):
> > On 2021-08-15 16:09:37 +0500, Andrey Borodin wrote:
> >> @@ -4573,7 +4649,7 @@ VirtualXactLock(VirtualTransactionId vxid, bool wait)
> >>      */
> >>     proc = BackendIdGetProc(vxid.backendId);
> >>     if (proc == NULL)
> >> -        return true;
> >> +        return WaitXact(vxid, InvalidTransactionId, wait);
> >> 
> >>     /*
> >>      * We must acquire this lock before checking the backendId and lxid
> >> @@ -4587,9 +4663,12 @@ VirtualXactLock(VirtualTransactionId vxid, bool wait)
> >>         || proc->fpLocalTransactionId != vxid.localTransactionId)
> >>     {
> >>         LWLockRelease(&proc->fpInfoLock);
> >> -        return true;
> >> +        return WaitXact(vxid, InvalidTransactionId, wait);
> >>     }
> > 
> > It seems like it's going to add a substantial amount of work even when
> > no 2PC xacts are involved?
> Only if 2PCs are enabled.

I don't think that's good enough. Plenty of systems have 2PC enabled but very
few if any transactions end up as 2PC ones.

Greetings,

Andres Freund



pgsql-bugs by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Next
From: PG Bug reporting form
Date:
Subject: BUG #17166: PREPARE without types inconsistent type resolving