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

From Andrey Borodin
Subject Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Date
Msg-id 364BAA98-1A3F-4C39-B0D9-ED8C40EA902D@yandex-team.ru
Whole thread Raw
In response to Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data  (Andres Freund <andres@anarazel.de>)
Responses Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data  (Noah Misch <noah@leadboat.com>)
List pgsql-bugs

> 29 авг. 2021 г., в 23:09, Andres Freund <andres@anarazel.de> написал(а):
>>>
>>> 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.

I could not compose significantly better solution. Let's consider what we actually pay for.

GetLockConflicts() returns xids for 2PC and vxids for any other transaction. Then we wait for each other one-by-one.
GetLockConflicts() cannot return xids for regular transactions: these xids may not have xid lock yet. So we have to
workwith vxid. 

Each wait case can resort to set of three possible actions: test/wait for xid (cheap), test/wait for vxid (relatively
cheap),search xid by vxid (expensive). 

When we have to wait for known-2PC we wait on xid (cheap).
When we have vxid:
1. If backend is not on the same vxid, we have to search xid by vxid (expensive). Then wait on obtained xid if any.
2. Either way wait for vxid, then for xid (cheap * 2).

So the really slow part is searching xids for long-gone vxids that may not have a xid at all.
We simply have no good mechanics to say that this vxid did not have a xid, if vxid is long gone.

Best optimisation I can imagine here is to gather all vxids with unknown xids and search for them in one call to
TwoPhaseGetXidByVXid()with one LWLockAcquire(TwoPhaseStateLock, LW_SHARED). 

Does it worth the complexity?

Best regards, Andrey Borodin.


pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #17166: PREPARE without types inconsistent type resolving
Next
From: "David G. Johnston"
Date:
Subject: BUG #17166: PREPARE without types inconsistent type resolving