> On 12 Jun 2026, at 06:04, Josh Curtis <[email protected]> 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.
