Re: Possible G2-item at SERIALIZABLE

From: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>
To: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Possible G2-item at SERIALIZABLE
Date: 2026-06-01 22:00:16
Message-ID: CAN4CZFOKnrRdHfd_SKcaNT33iV-QvLYyvUnO5aM2nuUipnug6A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

+ /*
+ * Mark ourselves doomed before raising the error. Otherwise a
+ * subtransaction abort (ROLLBACK TO SAVEPOINT) could swallow this
+ * error and let the transaction commit anyway, defeating SSI.
+ */
+ MySerializableXact->flags |= SXACT_FLAG_DOOMED;
LWLockRelease(SerializableXactHashLock);
ereport(ERROR,
(errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),

I wonder if it would make sense to introduce a
"DoomMyselfAndRaiseSerializationFailure" helper for this, while fixing
all occurrences we can find? That would make it more explicit, and
also less repeated.

> PFA attached isolation tester and hand-wavy fix. But I suspect there are more G-items
> around.

There are at least 2 more reproducible with the isolation tester in
CheckForSerializableConflictOut ("conflict out to old pivot %u", and
"conflict out to old committed transaction %u" directly below it).
Probably "Canceled on conflict out to old pivot." also should have the
same changes?

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Matheus Alcantara 2026-06-01 22:14:34 Re: BUG #19480: PL/Python SRF crashes (SIGSEGV) when function is replaced mid-iteration: use-after-free in PLy_funct
Previous Message Álvaro Herrera 2026-06-01 17:12:53 Re: BUG #19500: pgrepack logical decoding plugin can crash assert builds via SQL decoding API