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