mirror of
https://github.com/block/buzz.git
synced 2026-10-30 14:01:37 +00:00
0534277b4a
The previous concurrency regression used a tokio::sync::Barrier to
synchronize two connections before racing to INSERT the same revision.
That construction synchronizes client-side INSERT dispatch, not trigger
execution; a lock-free schedule where one INSERT completes and commits
before the other reads MAX still satisfies the XOR + 23514 assertions,
so the test offered no deterministic proof that pg_advisory_xact_lock
is required.
Replace with a controlled two-connection schedule:
1. tx1 opens a transaction and inserts revision 102. The BEFORE INSERT
trigger acquires pg_advisory_xact_lock and completes; tx1 holds the
advisory lock until commit.
2. tx2 opens a transaction on a second backend, reports its pg_backend_pid
over a oneshot channel, then issues INSERT for revision 103. The
trigger fires and blocks on the advisory lock held by tx1.
3. The main task polls pg_stat_activity WHERE pid = tx2_pid AND
wait_event_type = 'Lock' AND wait_event = 'advisory' with a 10 s
bounded timeout. Without pg_advisory_xact_lock in the guard the
trigger returns immediately, tx2 never enters the advisory wait, and
the poll times out — making the regression deterministically red.
4. tx1 commits, releasing the lock. tx2 unblocks, its trigger reads the
fresh MAX=102, and INSERT 103 succeeds. tx2 commits.
5. Final count asserts six revisions (1, 2, 100, 101, 102, 103).
Zero production changes: migrations/0041, migrations/0042, and
schema/schema.sql are byte-untouched (single-file diff confirmed).
Co-authored-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Will Pfleger <pfleger.will@gmail.com>
Signed-off-by: Hayt <9e1c23a3fd83f61da34420e4e88ff1b16e45cafcc0cd9019eb07d4ecfa8ca9b0@buzz.block.builderlab.xyz>