Re: Possible G2-item at SERIALIZABLE - Mailing list pgsql-bugs

From Zsolt Parragi
Subject Re: Possible G2-item at SERIALIZABLE
Date
Msg-id CAN4CZFOKnrRdHfd_SKcaNT33iV-QvLYyvUnO5aM2nuUipnug6A@mail.gmail.com
Whole thread
In response to Re: Possible G2-item at SERIALIZABLE  (Andrey Borodin <x4mmm@yandex-team.ru>)
List 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?



pgsql-bugs by date:

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