Re: Fix race condition in SSI when reading PredXact->SxactGlobalXmin

> On 12 Jun 2026, at 06:04, Josh Curtis <jcurtis825(at)gmail(dot)com> wrote:
>
> <v4-0001-Fix-race-condition-when-reading-PredXact-SxactGlo.patch>

Hi Josh,

I suspect a race in the test:

+step s2_insert_wait_at_page_split: <... completed>
+step s1_commit_wait_in_SetNewSxactGlobalXmin: <... completed>

Adding an explicit dependency can make the output stable:

s2_insert_wait_at_page_split(s1_commit_wait_in_SetNewSxactGlobalXmin)

I don't think we should acquire SerializableXactHashLock in shared mode
on every page split to fix this. The race exists because
SetNewSxactGlobalXmin() uses the shared fields as local variables and
publishes a transient InvalidTransactionId while recalculating them.

Could it instead calculate the new xmin and count in local variables,
then publish them after scanning the active list? Readers that use both
fields already hold SerializableXactHashLock. Lockless readers inspect
only SxactGlobalXmin and may safely see the previous valid value. That
can only cause unnecessary predicate-lock work. Publishing
SxactGlobalXmin last would preserve that property and the existing fast
path when no serializable transactions are running.

That seems both simpler and better for the page-split path. I think the
patch should fix the publication side instead of adding the three reader
locks. WDYT?

Thank you!

Best regards, Andrey Borodin.