Re: Potential G2-item cycles under serializable isolation

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Potential G2-item cycles under serializable isolation
Дата
Msg-id CAH2-Wzkk5CS2emjrftQXemjDVNkYSrUEXtHd-hoxBGsjSA01Ew@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Potential G2-item cycles under serializable isolation  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Potential G2-item cycles under serializable isolation  (Thomas Munro <thomas.munro@gmail.com>)
Re: Potential G2-item cycles under serializable isolation  (Andres Freund <andres@anarazel.de>)
Список pgsql-bugs
On Sun, Jun 7, 2020 at 7:54 PM Peter Geoghegan <pg@bowt.ie> wrote:
> The issue seems to be that heapam's mechanism for adding a "conflict
> out" can get some details subtly wrong. This can happen in the event
> of a concurrently updated tuple where the updating xact aborts. So for
> each pair of transactions that committed in each G2-Item, there seemed
> to be a third updating transaction that aborted, messing things up. I
> think that the "conflict out" stuff ought to behave as if an updated
> tuple was never updated when it's not visible to our xact anyway. We
> should use the XID that created the original tuple for "conflict out"
> purposes -- not the (possibly aborted) updater's XID (i.e. not the
> HeapTupleHeaderGetUpdateXid() XID).

The functionality in question (the code from the
HeapCheckForSerializableConflictOut() case statement) was originally
discussed here, with the details finalized less than a week before SSI
was committed in 2011:

https://www.postgresql.org/message-id/flat/1296499247.11513.777.camel%40jdavis#9e407424df5f8794360b6e84de60200a

It hasn't really changed since that time.

Kevin, Jeff: What do you think of the fix I have proposed? Attached is
a revised version, with better comments and a proper commit message.
Somebody should review this patch before I proceed with commit.

Thanks
--
Peter Geoghegan

Вложения

В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: