The locking change looks correct to me. On 21 Sep 2026, Aleksander Alekseev wrote: > +# other one read. No serial order produces sum(p) = 2, ...
The constant assignments in this test produce a final sum of 2 in either serial order too. The anomaly is that both preceding reads return 0. Could we correct the comment? The test itself demonstrates the bug. Maybe we could also cover inserts after scanning an initially empty table. That would guard against moving lock acquisition into a per-page path later: there are no existing pages to lock. Without the fix both transactions commit; with v2 one is aborted. Thank you! Best regards, Andrey Borodin.
