mirror of
https://github.com/block/buzz.git
synced 2026-11-07 01:41:06 +00:00
0d5edb8bb3
## Summary A newest-first `events` read whose own `since` is at or above the recent-pass floor now runs as a single recent pass. Postgres prunes it to the recent monthlies at plan time instead of locking every partition. Results are unchanged. **Why.** `split_for` skipped any read whose `since` was at or above the floor (`since_prunes`), on the theory that its `since` already prunes. It does, but only as a bind parameter. Once a prepared statement switches to a cached generic plan, Postgres prunes bind-parameter bounds at execution, after `AcquireExecutorLocks` has already locked every `events` partition and its indexes. Live REQs with a recent `since` are this shape, for example `#p` mention reads from reconnecting agents. Under load they spill past the 16 fast-path lock slots and contend on `LWLock:LockManager`. The ceiling PR (#9157) named this gap as identified debt. **What changes.** Such a read now gets the same `Split` as other recent reads, so the recent pass carries the floor literal (plus the ceiling literal for regular-kind reads) on `e.created_at` and on `m.event_created_at` for `#p`. `Split` gains `older: bool`. It is false when the read's own `since` is at or above the floor, because no row below the floor can match, so no older pass follows a short recent pass. A read whose `until` falls below the floor stays unsplit, as before. No protocol, schema, index or client change. ### Related issue Follow-up to #9157 (its identified debt: bind-parameter `since` reads). ### Testing - `recent_pass::tests::split_eligibility`: the table now records not split / ceiled / open and whether an older pass follows. New rows: `since` at the floor, a recent `since` with regular, any and addressable-only kinds, and a recent `since` with `until` below the floor. - `recent_pass::tests` in-memory exactness: adds a `since`-at-floor split that runs exactly one pass and returns the rows at or above the floor. - `postgres_tests::since_bounded_mention_read_locks_only_recent_partitions` (new): runs partition maintenance, inserts `#p` rows at the floor, now, one second below the ceiling and one day below the floor, then reads with `since = floor`. The production path returns the three recent rows through the mention join. Under `plan_cache_mode = force_generic_plan` the recent pass locks only the partitions holding those rows. The unsplit read locks every partition. - The partition-lock helper from #9157's test is now shared by both lock tests. - Diagnostic on Postgres 17.11 with the 19-partition layout partition maintenance keeps, for a `#p` read with `since` at the floor (not committed): | | `events` partitions locked | Relation locks | Non-fast-path locks | |---|---|---|---| | Before (bind-only `since`, generic plan after five runs) | 19 | 26 | 10 | | After (floor and ceiling literals) | 2 | 9 | 0 | `EXPLAIN (GENERIC_PLAN)` before appends all 19 partitions. After, it appends only the previous and current monthlies. Mutation-checked on Blox. Each of these fails the new Postgres test or the unit tests: removing the `since_prunes` split, ignoring `older`, and dropping the `e.` literal. ## What got simpler Nothing got simpler. The change adds one flag to the existing `Split` type and no new concept. The duplicated partition-lock reader in the #9157 test became one shared helper. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Signed-off-by: Luke Tornquist <tornquist@squareup.com> Co-authored-by: Elrond <28d6302a099e5225b02c4155ac4236e4912603df2ab08dbfc2f4fef08ce598c8@buzz.block.builderlab.xyz> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>