Re: Possible G2-item at SERIALIZABLE

> On 19 Aug 2026, at 20:24, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
>
> I attached a reworked patch that introduces 2 helper macros (functions
> would be more complex with va args), and converts existing uses to
> using them, dooming some scenarios, and extending the test coverage.
> <v2-0001-Doom-the-serializable-transaction-before-raising-a-s.patch>

Hi Zsolt,

I read v2 and agree with the invariant it introduces. As far as I can
tell, the patch covers all serialization failure paths in predicate.c
correctly: newly detected failures doom the current transaction, while
the paths that find it already doomed only re-report the error. Copying
writer->topXid before releasing SerializableXactHashLock also looks
right.

I agree with the conservative choice for a failure detected during a
write. It may cause an unnecessary retry when the subtransaction rolls
back that write, but a whole-transaction retry is the expected response
to a serialization failure anyway.

One test does not quite prove what its comment says. The "next read
re-reports" permutation repeats the same conflicting SELECT. The old
code raises another serialization failure there too, by rediscovering
the same dangerous structure rather than by noticing DOOMED. Could we
use an unrelated third row for that read? It should succeed without
the patch and fail immediately with it. The subsequent-write case
already distinguishes the two versions.

I also tested adapted versions on every supported branch. The patch
applies cleanly to 16 through 18; 14 and 15 only need mechanical changes
for the older SHMQueue representation and their isolation schedules.
The complete isolation test suite passed on each branch.

Thank you!

Best regards, Andrey Borodin.