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.
