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

Поиск
Список
Период
Сортировка
От Andrey Borodin
Тема Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Дата
Msg-id 364BAA98-1A3F-4C39-B0D9-ED8C40EA902D@yandex-team.ru
обсуждение исходный текст
Ответ на Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data  (Andres Freund <andres@anarazel.de>)
Ответы Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data  (Noah Misch <noah@leadboat.com>)
Список 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 по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #17166: PREPARE without types inconsistent type resolving
Следующее
От: "David G. Johnston"
Дата:
Сообщение: BUG #17166: PREPARE without types inconsistent type resolving