From: Zsolt Parragi <zsolt.parragi@percona.com>
In-Reply-To: <1F2F4318-437C-4AE1-8413-F94FBDD5AB68@yandex-team.ru>
References: <165342c0-0c75-461e-b334-b997639ad48d@aphyr.com>
 <1F2F4318-437C-4AE1-8413-F94FBDD5AB68@yandex-team.ru>
MIME-Version: 1.0
Date: Mon, 1 Jun 2026 15:00:16 -0700
Message-ID: 
 <CAN4CZFOKnrRdHfd_SKcaNT33iV-QvLYyvUnO5aM2nuUipnug6A@mail.gmail.com>
Subject: Re: Possible G2-item at SERIALIZABLE
To: pgsql-bugs@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAN4CZFOKnrRdHfd_SKcaNT33iV-QvLYyvUnO5aM2nuUipnug6A%40mail.gmail.com>
Precedence: bulk

+			/*
+			 * 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?