Re: Potential G2-item cycles under serializable isolation

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Kevin Grittner <kgrittn(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Kyle Kingsbury <aphyr(at)jepsen(dot)io>
Subject: Re: Potential G2-item cycles under serializable isolation
Date: 2020-06-09 01:26:01
Message-ID: CAH2-Wzkk5CS2emjrftQXemjDVNkYSrUEXtHd-hoxBGsjSA01Ew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sun, Jun 7, 2020 at 7:54 PM Peter Geoghegan <pg(at)bowt(dot)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

Attachment Content-Type Size
v2-0001-Avoid-aborted-update-serialization-anomalies.patch application/octet-stream 3.1 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2020-06-09 01:36:31 Re:
Previous Message Tom Lane 2020-06-09 00:11:43 Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan