notify-bench: harness isolating the NOTIFY commit lock (fork-local)

[NikolayS]

Fork-local infrastructure. Never intended for upstream. Everything here lives under notify-bench/ and would not be proposed to -hackers in this form. The upstream-bound patch is the documentation change in #83, which this PR supplies the supporting measurements for; background and analysis are in #82.

Why it exists

The obvious experiment — compare INSERT against INSERT; NOTIFY — does not isolate the lock. It measures the lock plus the SLRU queue insert, the utility statement itself, and an extra client round trip. Any speedup it shows is unattributable.

notify-bench/instrumentation/0001-MEASUREMENT-ONLY-skip-notify-commit-lock.patch fixes that. It makes the identical binary skip only the LockSharedObject() call in PreCommit_Notify() when PG_NOTIFY_NOLOCK is set in the postmaster environment. Both arms run the same executable, the same SQL, the same number of round trips, and insert the same queue entries; they differ by that one call.

The skip is semantically unsafe — it breaks the commit-order guarantee that the lock exists to provide. It is a measurement device, not a proposed optimization, and the patch is named accordingly.

Headline result

synchronous_commit=on, zero listeners, 3 reps, median [min-max] TPS:

clients	control (INSERT)	NOTIFY, lock held	NOTIFY, lock skipped	speedup from lock removal	gap recovered
4	2,059	1,033	2,177	2.1x	111%
16	7,811	1,027	7,893	7.7x	101%
64	16,307	1,055	12,369	11.7x	74%

The gap recovered column is the point. If NotifyQueueLock — the SLRU queue lock — simply became the next bottleneck once the heavyweight lock was gone, removing the heavyweight lock would buy little. It does not: through 16 clients the no-lock arm reaches the NOTIFY-free control, and at 64 clients the residual is only ~26% of the gap. The commit-time lock, not the queue, is what bounds notifying throughput here.

The hardware-independent framing

Absolute TPS on a 4-vCPU box is not interesting. The wait-event data is, because it holds regardless of how fast the disk is: both arms run with exactly one fsync in flight at all times. The difference is what is queued behind it. The control arm has ~21 backends waiting on that one flush and group-committing with it; the NOTIFY arm has zero, because those backends are stuck a step earlier, waiting for the object lock and not yet in the commit path at all.

Group-commit batch factor ~21 versus exactly 1. That ratio is a property of the serialization, not of this storage.

Known defects — documented, not hidden

notify-bench/README.md enumerates these. The most important one invalidates a result:

• The psql -f <fifo> listeners never call PQconsumeInput. They jam in ClientWrite instead of draining the queue. scripts/checkjam.sh demonstrates it directly: 50 of 50 listeners wedged. This flatters master and punishes v18 — that is, the bias runs in favour of the conclusion the harness was built to test, which is the worst direction for it to run. The "interested listener" results are therefore retracted. The uninterested-listener results, including the table above, do not depend on listener draining and are unaffected.

Also, in decreasing order of severity:

• Single samples everywhere outside ab_lock.csv — no repetition, no dispersion.
• The synchronous_commit=off rows sit at roughly a 50% noise floor; differences there are not meaningful.
• A 4-vCPU box with pgbench and the listener processes co-resident with the server, so the load generator competes with what it measures.
• No latency percentiles recorded, only throughput.
• No synchronous replication configured, although sync rep is exactly the case where the serialized region is longest and the effect should be largest.
• The test table uses a bigserial primary key, whose sequence and index contention cap the control ceiling — in both arms, so it compresses the measured gap rather than inflating it.

None of this is publication-ready. The README lists what has to be fixed before any of these numbers should be quoted outside this repository. It is checked in so the measurements behind #83 are reproducible and auditable, defects included.

🤖 Generated with Claude Code

https://claude.ai/code/session_01M3RLizCyeXBBFJdBHGDvKW

---

Generated by Claude Code

[NikolayS]

CI: Windows - Visual Studio - Slice 2/2 failed. Not caused by this branch — diagnosis below so it isn't re-investigated.

The failure is a single test out of 198:

Summary of Failures:
 84/198 ecpg - postgresql:ecpg/ecpg    ERROR    21.19s   exit status 1

Ok: 180   Fail: 1   Skipped: 17

Two independent reasons it can't be attributable to this PR:

1. The diff cannot reach ecpg. All 16 files are additions under notify-bench/ — shell scripts, CSVs, a README, a stored .patch, and a .gitattributes. Nothing is compiled, and nothing is referenced by meson or the makefiles. There is no path from this change to the ecpg test suite.
2. The identical job passed on doc: document LISTEN/NOTIFY commit-time serialization #83, which is built from the same base commit (13b7a8a0) and likewise changes no C code.

So this is a flaky or environment-specific ecpg failure on the Windows VS runner, not a regression. SanityCheck — the job the second commit's .gitattributes was written to satisfy — passed, along with Linux Autoconf, Linux Meson 32-bit, macOS Meson and CompilerWarnings.

I tried to re-run the failed job immediately; the API rejected it with 403 This workflow is already running because other jobs in the run are still in flight. I'll re-run it once the workflow completes and update here only if it fails a second time — at which point it stops being a flake and needs real investigation.

---

Generated by Claude Code