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:
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 |
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 |