Roadmap item 8. Gates items 1–4 and 10, and specifically item 4: a lever you walk up to and pull is far more persuasive than a slider in a panel, so a lever wired to a knob with a wrong consequence chain is a machine for teaching a falsehood convincingly.

Original scope: the 23 fields of Knobs in src/core/types.ts:75. The disaster-recovery addendum below audits the four controls added by roadmap item 1, and the three-node addendum audits the three controls added by roadmap item 2. The failover addendum audits four controls added by roadmap item 3, and the synchronous-replication availability fix adds one control. The work_mem addendum adds the thirty-sixth field. Method: read every consumer, then drive the model directly — createSim() with a stub bus, setKnob(), update(1/30), seeded RNG, 300–400 s of warm-up before every reading, and an explicit down-sweep afterwards to test recovery. Every number quoted below is measured, not estimated.

Original verdict count (2026-07-29 snapshot): 13 CORRECT, 10 WRONG, 0 MISSING.

The pooler work adds five controls. All five pass the executable response sweep in src/sim/knob-response.test.ts, and the boundary semantics have focused coverage in src/sim/pooler.test.ts.

Connection-storm before/after measurement. The seeded scenario was read at 30 model steps/s: direct mode over t=28–43 s, then the transaction-pool state over t=76–95 s. These are model-time teaching values, not production forecasts.

Both sides receive the full 3,200 tps offered workload: the direct phase has sixteen admitted client connections, while the pooled phase admits 1,000 client sockets and targets eight PostgreSQL servers. Connection churn makes the direct backend count fluctuate; the sample caught fifteen, so its pressure multiplier was 2.914 versus 1.0 at the pooled knee. Pooling removes modeled connection churn and lowers backend pressure, but it does not change an assigned statement's plan or executor cost. In this run throughput is lower after pooling and the retained queue's measured FIFO age dominates latency; no work expires before the 120-second timeout. Component quantiles are independent, so p99 values are not additive.

The roadmap says "eleven of twenty-two". This audit re-grades four of them and adds three the earlier sweep passed; see Changes from the previous sweep.

This document records the original audit rather than silently replacing it. Its numeric src/sim/model.ts line references describe the 2026-07-29 source snapshot and no longer resolve against current main; use the named functions and regression tests below for current navigation.

All ten original WRONG verdicts were re-run against current main on 2026-07-31 and are now CORRECT. For the original 23-knob scope, the current count is therefore 23 CORRECT, 0 WRONG, 0 MISSING.

The audit's separate RC-5 finding is also fixed: wal_buffers auto-tuning verifies shared_buffers / 32 with PostgreSQL's 64 KiB floor and one-segment cap. RC-4's current evidence is listed with knob 9 above. The detailed sections below retain their original measurements and WRONG labels as historical evidence; they are not the current verdicts.

Follow-up for a later storage-model audit (2026-08-02): the no-bgwriter scenario drives 5.0–54.0 representative writes/s and 15.3–87.8 reads/s against DEVICE_PAGES_PER_SEC = 900. Reads and writes together occupy about 7.8% of the modeled device in the audited run. The shared finite-storage-pressure lesson is therefore still lightly loaded at these knobs. This latency fix does not recalibrate that separate mechanism.

Eight of the ten WRONG verdicts trace to six shared defects. Fix these and most of the table clears without touching the knobs individually.

Measured. Identical workload (tps 300, writeRatio 0.6), 200 s window after 300 s warm-up:

Vacuum produces 9× the WAL of the workload that created the garbage and takes 75 % of the throughput. On a real server, vacuuming a relation that is ~2 % dead writes a small fraction of the WAL that the DML wrote, because one XLOG_HEAP2_PRUNE_VACUUM_SCAN record covers every dead line pointer on a page.

Cause A — one full-page image per vacuumed page, charged twice per pass. walInsertPage() (src/sim/model.ts:1328) charges a ~6.5 KiB image for every page vacuum modifies. vacHeapModified (src/sim/model.ts:1958) is pages × (1 − e^(−dead/pages)), which for a 220 000-page relation with 200 000 dead tuples is ~135 000 pages. Both scan_heap (:2029) and vacuum_heap (:2081) walk that same set, and because a pass lasts far longer than a checkpoint interval, fpiGeneration has advanced in between, so most pages pay a second image inside one pass. Result: hundreds of MiB of WAL per vacuum pass.

Cause B — no vacuum cost delay. The model has no analogue of vacuum_cost_delay / autovacuum_vacuum_cost_delay. scan_heap charges ioReadAcc += t.pages × dt / (t.pages/900) = 900 pages/s per worker; three workers is exactly DEVICE_PAGES_PER_SEC (src/sim/model.ts:255). Autovacuum therefore saturates the modelled device by construction, which is precisely the thing PostgreSQL's cost-based delay exists to prevent.

Right behaviour.

• Give each vacuum worker a cost budget. PostgreSQL: vacuum_cost_page_hit = 1, vacuum_cost_page_miss = 2 (10 before PostgreSQL 14), vacuum_cost_page_dirty = 20, vacuum_cost_limit = 200, autovacuum_vacuum_cost_delay = 2ms (20 ms before PostgreSQL 12). The worker sleeps for cost_delay whenever accumulated cost exceeds cost_limit. Model it as a per-worker rate cap that leaves headroom on DEVICE_PAGES_PER_SEC — a sensible scaled target is that all three workers together consume no more than ~25 % of the device, so foreground work still gets served.
• Charge a full-page image once per page per checkpoint generation across the whole pass, not once per phase. Pin the generation at pass start.
• Only pages that actually contain removable dead tuples should be modified. scan_heap should emit WAL only for pages it prunes; the read of the rest of the relation is I/O, not WAL. Today scan_heap and vacuum_heap each emit a record for every page in vacHeapModified.

Timescale and settling point. With the workload above, vacuum WAL should settle at well under the foreground WAL rate — target 10–30 % of it, i.e. 50–160 KiB/s against 540 KiB/s, not 4 400 KiB/s. The full-page-image share should land near the autovacuum = false value (0.65), not 0.98.

Knobs this unblocks: tps, writeRatio, fullPageWrites, autovacuum, checkpointTimeout (partly).

src/sim/model.ts:2273:

if (!rep.enabled || K.walLevel === 'minimal') {
  …
  rep.lagBytes = Math.max(0, wal.flushLsn - rep.replayLsn)
  updateReplayLag()
  return
}

The early return is above the logical-decoding block (:2383), so rep.logicalSlotLsn and rep.logicalChangesPerSec are never updated. It is also above everything that advances rep.replayLsn, so updateReplayLag() measures the age of a pointer that will never move again. And tickSegments() (src/sim/model.ts:1605) computes slotHold from rep.flushLsn under if (rep.enabled), which is still true at wal_level = minimal.

Measured, fresh sim at wal_level = minimal, tps 300, writeRatio 0.6:

max_wal_size is 256 MiB. Every one of those numbers is impossible: at wal_level = minimal there is no standby, no replication slot and no replay position. logicalChangesPerSec behaves the same way — after logical → minimal it holds 41.6 changes/s indefinitely, beside a card that reads "off — wal_level is not logical".

The same freeze fires on standbyAEnabled = false: measured lagSec 300.37, lagBytes 1.6 GiB, slot retention 1.6 GiB, with connected = false.

Right behaviour. Restructure tickReplication() so the disconnected branch normalises rather than returns:

• rep.logicalEnabled = K.walLevel === 'logical' && rep.enabled && rep.connected.
• When not logical: rep.logicalSlotLsn = wal.insertLsn (so derived retention is zero, not negative and not stale) and decay logicalChangesPerSec toward 0 at the existing rate 3 — visible decay over ~1 s, which is honest for a decoder that has stopped.
• When there is no standby: rep.replayLsn = rep.flushLsn = rep.writeLsn = rep.sentLsn = wal.flushLsn, lagBytes = 0, lagSec = 0. The fact to surface is "no standby", not "a standby that is 342 s behind". pg_wal retention must fall back to max(sinceRedo, 0) so it is bounded by max_wal_size again.
• slotHold must be gated on rep.connected, not rep.enabled.

Also fix the readouts, which are guarded on the wrong field. Six places guard on replication.enabled/connected and four do not:

src/observability/views.ts:744 (pg_stat_replication) and :967 (slots) are already correctly guarded and disagree with the panels — that disagreement is the cheapest regression test available.

Knobs this unblocks: walLevel, standbyAEnabled.

src/sim/model.ts:591-600: 93 % of heap writes land in hotPages, which is clamp(round(pages × 0.0001), 8, 32) — at most 32 pages per relation. The other 7 % land uniformly across the whole relation (219 000 pages for accounts).

There is nothing in between. The hot set is re-modified many times inside any checkpoint interval, so it pays essentially no full-page images per unit time. The cold set is never re-modified, so every cold write pays an image no matter how far apart checkpoints are. Full-page-image bytes per second is therefore almost independent of checkpoint_timeout, which removes the entire reason that GUC exists.

Measured, autovacuum = false, writeRatio 1, updateRatio 1, seqScanRatio 0, max_wal_size 4096 so the timer governs:

Right behaviour. Add a warm band: a few thousand pages per relation that a 15 s interval touches once or twice and a 300 s interval touches dozens of times. Concretely, replace the two-way split with three:

• hot (~60 % of writes): today's hotPages, 8–32 pages — repeats constantly.
• warm (~35 % of writes): clamp(round(pages × 0.02), 512, 8192) pages, drawn with the same u² skew — this is the band checkpoint_timeout acts on.
• cold (~5 % of writes): uniform over the relation — the irreducible floor.

With that split, doubling checkpoint_timeout should move the full-page-image share by roughly a factor of two over the range where the warm band is being revisited (roughly 15 s → 300 s here), and flatten out beyond it — which is also what happens on a real server, and is the honest shape.

Do not simply shrink the cold share to zero. A uniform-random write workload over a relation far larger than one checkpoint's worth of writes genuinely gets no benefit from a longer interval, and the model should still be able to show that.

Knobs this unblocks: checkpointTimeout.

writeOut(b, byBackend) at src/sim/model.ts:1148 increments ioWriteAcc and buf.dirtyEvictions and emits a flow particle. It does not extend the evicting backend's stateDur or execTotal. The only coupling back to latency is the global, 250 ms-lagged, quadratic ioLoad in tickStats().

So the model reproduces the bgwriter's cost (extra writes of pages that get re-dirtied) and none of its benefit. In PostgreSQL, BufferAlloc() → FlushBuffer() is synchronous for the backend that needs the frame, and it must XLogFlush() the page's LSN first — that is the whole reason the background writer exists.

Right behaviour. In touchPage()'s miss path, when writeOut(v, true) actually writes a dirty frame, charge the requesting backend a synchronous write cost — add it to x.execTotal and to the current stateDur. A scaled cost of one device write plus the queue in front of it, i.e. (1 / DEVICE_PAGES_PER_SEC) × ioPressure() per dirty eviction, is the smallest honest version and is already dimensionally consistent with beginExec().

Knobs this unblocks: bgwriterEnabled.

src/sim/model.ts:104:

/** wal_buffers: PostgreSQL auto-tunes this to shared_buffers/32 → 256 KiB here. */
const WAL_BUF_CAP = 256 * 1024

The arithmetic does not hold: shared_buffers = 2GB divided by 32 is 64 MiB, capped at one WAL segment, so PostgreSQL's wal_buffers = -1 resolves to 16 MiB, not 256 KiB. 256 KiB corresponds to shared_buffers = 8MB. And it is a module constant, so the value does not follow the knob at all:

Two shipped passages state the correct rule beside the wrong number: src/ui/docs-memory.ts:1019 ("one thirty-second of shared_buffers capped at one 16 MiB segment") and src/ui/docs-storage.ts:163 ("the default of 1/32 of shared_buffers (capped at 16 MiB)"), while src/ui/docs-memory.ts:1028 prints s.wal.bufferCapacity.

Right behaviour. Derive it in resizePool(): wal.bufferCapacity = clamp(poolBytes(K) / 32, 64 * 1024, WAL_SEG). This is not currently load-bearing for a bottleneck — measured wal_buffers occupancy stayed at 0 % up to 11.7 MiB/s of WAL — so it is a low-risk correction of a printed number that contradicts the paragraph above it.

src/sim/model.ts:209 stretches configured network delay by 6× into simulated seconds. src/sim/model.ts:109 exports MODEL_TIME_STRETCH = 100 for UI disclosures. Measured replay_lag against the configured one-way delay:

The control is labelled in real milliseconds; pg_stat_replication.replay_lag and the HUD's "Repl lag" are labelled in real seconds. A fixed, undisclosed 6× distortion sits between them.

Right behaviour. Report replication timings in real units: divide by NET_STRETCH on the way out (rep.lagSec, commitWaitEstimate()'s network term, and the standby's TX_LAT readout), keeping the 6× only inside the scheduling of wireAt / ackAt where it buys visible packet travel. A 400 ms one-way delay should then report ~0.4–0.5 s of replay_lag and a remote_apply commit wait of roughly one round trip. If the stretch is kept instead, the disclosure must name 6× wherever a replication duration is printed — but reporting real units is the better answer, because replay_lag is a number operators are expected to compare against a real server's.

autovacuum (boolean, default on) controls whether the postmaster runs the autovacuum launcher. With track_counts on, the launcher wakes every autovacuum_naptime (default 60 s) and starts a worker per database; a worker vacuums every relation where

n_dead_tup > autovacuum_vacuum_threshold + autovacuum_vacuum_scale_factor × reltuples

(defaults 50 and 0.2), or, since PostgreSQL 13,

n_ins_since_vacuum > autovacuum_vacuum_insert_threshold + autovacuum_vacuum_insert_scale_factor × reltuples

(defaults 1000 and 0.2). At most autovacuum_max_workers (default 3) run at once. Crucially: even when autovacuum is off, the system still launches autovacuum workers to prevent transaction ID wraparound, once a relation's age(relfrozenxid) exceeds autovacuum_freeze_max_age (default 200 million).

1. n_dead_tup climbs monotonically at the rate the workload manufactures dead row versions, minus what HOT pruning reclaims opportunistically.
2. Once dead tuples exceed the free space on their pages, the relation is extended: pg_relation_size grows and never comes back.
3. Index size grows too, because a non-HOT UPDATE and every DELETE leave index entries that only vacuum removes.
4. The cache hit ratio degrades as the same live rows spread over more pages.
5. Sequential scans and index scans both slow down for the same reason.
6. The visibility map stops being maintained, so index-only scans stop being index-only.
7. Eventually, wraparound protection starts vacuums anyway, regardless of the setting.

At shipped defaults (tps 10, writeRatio 0.2, updateRatio 0.6) — which is the state a visitor who walks up to a lever is in:

After one simulated hour, the worst-affected relation is 0.58 % dead and has not grown by a single page. The autovacuum yard's landfill counter never moves because no vacuum is due. The shipped hint (src/ui/content.ts:231) promises "watch dead rows pile up until the tables are mostly corpses"; reaching 50 % bloat at this rate would take roughly 60 simulated hours.

Under a hard workload (tps 500, writeRatio 0.8, updateRatio 1) the mechanism is visible and correct:

That is the right shape. events staying at 0 % is correct and is a good lesson — it is append-only and never the target of an UPDATE or DELETE.

Turning it back on, from the 42.8 % state:

Bloat comes down, relation size correctly does not. But for the first 60 seconds nothing at all happens, and three of four relations are untouched for five simulated minutes. The delay is structural: AV_NAPTIME is 12 s, then a 2 s travel phase, then scan_heap runs for max(pages/900, 1.2) seconds — 58 s for sessions at 52 000 pages, 250 s for accounts at 225 000, and only three workers exist for five relations.

WRONG. Four separate defects:

1. The consequence is invisible at the settings a visitor is in. The lever must produce a legible change within a visit. Target: with the shipped default workload, the hottest relation should cross 5 % bloat inside ~2 simulated minutes and keep climbing, and its page count should be visibly growing within ~5 minutes. That requires the dead-tuple production rate per transaction to be scaled against relation size the way everything else in the city is scaled for observation — either by raising the per-statement row counts on the small hot relations, or by shrinking sessions/documents toward a size where the default workload can actually bloat them. Do not raise the default tps: that changes every other lesson.
2. Turning it off is rewarded with throughput. Measured 113 → 239 tps at tps 300, and 48 → 190 tps at tps 300, writeRatio 0.6. That is RC-1: the model's vacuum is so expensive that switching it off looks like free performance, with no offsetting degradation over the following ten minutes. After RC-1, disabling autovacuum should give a small immediate bump (single digit percent) that is then progressively eaten by growing relations and a falling cache hit ratio.
3. Re-enabling shows nothing for a minute. The first worker should reach a relation and start returning dead tuples to the landfill within ~10–15 simulated seconds. Keep scan_heap's cost proportional to relation size — that is true and worth teaching — but cap the phase so the largest relation scans in ~20 s rather than ~8 minutes, and let vacuum_heap begin collecting from the pages already scanned rather than waiting for the whole scan. Real vacuum interleaves: it fills maintenance_work_mem with dead TIDs, vacuums the indexes, vacuums the heap, and then continues scanning. Modelling that loop is what makes progress visible.
4. No wraparound safety valve. The model has no age(relfrozenxid) and never launches a worker while autovacuum = false. This is one of the most important things about the setting and the reason "turn autovacuum off" does not simply stop vacuuming forever. Add an xid-age counter per relation that advances with state.xid, and launch a worker regardless of K.autovacuum once it crosses a scaled autovacuum_freeze_max_age, with a toast naming it. This is also a prerequisite for roadmap item 10 — "the disk is filling, what do you do" has a wraparound sibling that is strictly worse.

Real setting. Maximum time between automatic checkpoints, default 5 min. CheckpointerMain() schedules start-to-start from last_checkpoint_time, which is stamped when a checkpoint begins. Longer intervals mean fewer full-page images (each page pays at most one image per checkpoint cycle, on its first modification after the redo point) and a longer crash-recovery replay.

What the model does. Schedule: correct — 40 / 9 / 3 / 3 / 3 checkpoints at 15 / 60 / 300 / 600 / 1800 s, correctly handing over to max_wal_size once the timer is no longer the binding constraint. Crash-recovery volume (docs-storage.ts:1490) responds correctly. WAL and full-page-image volume do not: 955 / 957 / 976 / 976 / 976 KiB/s and a full-page-image share of 0.716 / 0.678 / 0.653 / 0.653 / 0.653 across a 120× range of the setting.

Verdict: WRONG (magnitude). Half of the trade-off the knob exists to teach is missing, and src/ui/content.ts:208 states it explicitly: "Longer means less write amplification but slower crash recovery."

Fix: RC-3, and RC-1 (vacuum's per-page images dominate the total and are interval-independent). Target after the fix: doubling checkpoint_timeout from 15 s to 30 s and again to 60 s should each cut the full-page-image share by roughly a third to a half, flattening once the interval exceeds the warm band's revisit period.

Recovery: schedule and segment retention return exactly. Cumulative checkpoint counts do not and should not.

Real setting. There is no bgwriter on/off GUC; the shipped hint says so correctly. bgwriter_lru_maxpages = 0 disables the cleaning loop. The writer wakes every bgwriter_delay (200 ms), scans a window ahead of the clock hand sized by bgwriter_lru_multiplier × recent allocations, and writes dirty buffers with usage_count = 0 so that a backend needing a frame finds it clean.

What the model does. Direction on backend writes: correct — measured 20 100 → 15 300 dirty evictions with the writer on (−24 %), and buffers_backend-equivalent falls at every pool size. Direction on throughput: inverted — 474.9 → 421.7 tps (−11 %) in a clean A/B at tps 1500, sharedBuffers 512, autovacuum off; and 181.6 → 140.9 tps (−22 %) in a second configuration. Total device writes rise (73.6 → 124.0 pages/s), because the writer cleans pages that are then re-dirtied.

Verdict: WRONG (direction). The model produces only the writer's cost. The documented benefit — "backend writes climb and query latency picks up a long tail almost immediately" when you turn it off, src/ui/docs-storage.ts:1024 — cannot be observed because RC-4 means backend writes are free.

Fix: RC-4. After it, enabling the writer should move latency and throughput by a few percent in the favourable direction on a churning workload, while buffers_backend falls by the 20–30 % already measured. The extra total writes should stay — that is real, and is why an over-aggressive writer is not free.

Recovery: symmetric and already correct — toggling back off restores the dirty/backend-write regime immediately.

Real setting. bgwriter_lru_maxpages, default 100, range 0–1073741823. The maximum buffers the writer may write in one round; at the default bgwriter_delay that caps it at 500 pages/s. It binds only when the writer is being outrun.

What the model does. tickBgwriter() (src/sim/model.ts:1810) loops while (scanned < lookahead && cleaned < K.bgwriterLruMaxpages). lookahead is clamp(round(ioReadPerSec × 0.5 + 32), 16, 420) and the scan wraps modulo buf.sampleFrames, which is 32–1024 frames. The binding constraint is therefore always the number of eligible frames (dirty, usage_count = 0, unpinned) inside a pool that is at most 1024 frames — never the cap.

A separate sweep at tps 2000, writeRatio 0.8 found 10, 50, 100, 200, 400 and 1000 all bit-for-bit identical.

Verdict: WRONG (inert above ~100). src/ui/docs-storage.ts:1024 and src/observability/paths.ts:1022 both recommend raising it to a few hundred; the model cannot show any difference. Because it is also fully redundant with bgwriterEnabled at the zero end, it currently carries almost no information.

Fix options, in order of preference:

1. Make the cap reachable by making the eligible set bigger under churn. lookahead should track allocations, not reads: bgwriter_lru_multiplier (2.0) × allocations per bgwriter_delay, smoothed — PostgreSQL's BgBufferSync() uses exactly that. On a 1024-frame pool being churned end to end that produces hundreds of eligible frames per round, and 100 vs 400 separates.
2. Failing that, merge the two bgwriter knobs into one (bgwriter_lru_maxpages, 0 = off) so the rail stops implying an independent effect that does not exist, and do not give the numeric one a lever.

Recovery: returning to 0 correctly stops cleaning; symmetric.

Real setting. off — commit returns before WAL is written; you can lose the last wal_writer_delay × 3 of committed transactions, but never corrupt. local — wait for local flush only, regardless of synchronous_standby_names. on — wait for local flush and, if synchronous_standby_names is set, for the standby's flush. remote_write — standby has written but not fsynced. remote_apply — standby has applied, so a read there sees the transaction. With synchronous_standby_names empty, on, remote_write and remote_apply all degrade to local.

What the model does. src/sim/model.ts:3201: off returns after 0.012 s; remote_apply waits for ackedApplyLsn; everything else waits for local flush only. Measured commit-wait occupancy: 71 / 1964 / 1964 / 2433 samples for off / local / on / remote_apply; tps 191 / 127 / 127 / 62.

Verdict: WRONG (internally inconsistent). on ≡ local asserts that synchronous_standby_names is empty. remote_apply making commits wait for the standby asserts it is not. The shipped text (src/ui/content.ts:258, src/ui/docs-storage.ts:1384) explains away the first assertion without noticing that it contradicts the second.

Fix. Declare a synchronous standby whenever standbyAEnabled is on, and give on the guarantee it actually has:

off          → no wait
local        → wal.flushLsn >= commitLsn
on           → wal.flushLsn >= commitLsn && ackedFlushLsn >= commitLsn
remote_apply → wal.flushLsn >= commitLsn && ackedApplyLsn >= commitLsn

ackedFlushLsn needs the same acknowledgement ring as ackedApplyLsn, sent when rep.flushLsn advances rather than rep.replayLsn. The observable result is a three-step ladder — local < on < remote_apply — where on costs one round trip and remote_apply costs one round trip plus apply time. That is the lesson, and it is currently a two-step ladder with a false middle. When standbyAEnabled is off, on correctly collapses onto local and remote_apply should warn (the "waiting for a synchronous standby that is not there" toast at src/sim/model.ts:3208 already exists).

Recovery: symmetric and correct — returning to off drops commit wait immediately.

Real setting. minimal — only what crash recovery needs; some bulk operations skip WAL entirely; incompatible with archive_mode = on and with any standby (the server refuses to start with both). replica (default) — adds what archiving and hot standby need. logical — adds what logical decoding needs, most importantly the old tuple's replica identity on UPDATE/DELETE and, in log_heap_update(), disabling the prefix/suffix compression that a non-logically-logged update gets.

What the model does right.

• WAL volume: minimal and replica identical, logical larger (src/sim/model.ts:2863, updBody = logical ? tup : max(24, tup × 0.35)). Measured 3 100 KiB/s at replica vs 6 500 KiB/s at logical. The mechanism is precisely right and cited correctly — heap_update() only computes prefix and suffix when !need_tuple_data, and need_tuple_data is RelationIsLogicallyLogged(reln).
• Archiver off at minimal (archiverOn(), src/sim/model.ts:1504) — measured archived = 0. Correct.
• Standby disconnected at minimal, with the right toast. Correct.

What is wrong. Everything in RC-2. The headline numbers a visitor sees at wal_level = minimal are 4.92 GiB of pg_wal against max_wal_size = 256 MiB, 4 800 MiB "held by the slot", 342 s of replay_lag, and 41.6 logical changes/s.

Verdict: WRONG. Fix per RC-2.

Recovery: minimal → replica restores the physical stream correctly (measured lagSec 0.00, changes 0). logical → replica → logical does not reset the slot position and must, once RC-2 normalises logicalSlotLsn. Cumulative wal.archived legitimately does not reset.

Real setting. When on, the first modification of a page after each checkpoint writes the whole 8 KiB page into WAL, so replay can start from a page it trusts even if the OS wrote it torn. Turning it off is safe only on storage that guarantees atomic 8 KiB writes.

What the model does. markDirty() (src/sim/model.ts:1306) and walInsertPage() (:1328) both honour it, keyed by page and checkpoint generation — which is the right rule (page.LSN <= RedoRecPtr, not residency). Measured WAL ratios (on ÷ off), same workload:

And throughput: 255.8 tps with images on vs 477.5 with them off — a 1.9× reward for disabling torn-page protection.

Verdict: WRONG (magnitude, in the shipped configuration). The mechanism is correct; RC-1 makes it read as a near-doubling of throughput for a setting whose real answer is "leave it on". Real full-page-image share on an OLTP server is typically 30–70 % of WAL; 95.5 % is not.

Fix: RC-1. No change to the full-page-image logic itself. After RC-1 the ratio should sit near the measured 1.9× and the throughput difference should fall to single-digit percent except on a genuinely WAL-bound workload.

Recovery: symmetric and correct — wal.fpwBurst is zeroed on the way down (src/sim/model.ts:3600) and fpiGeneration is bumped on both transitions.

Real setting. Whether a physical standby is streaming. If it streams through a replication slot, the slot pins WAL on the primary even when the standby is gone — the most reliable way to fill a production disk. Without a slot, the primary recycles WAL and the standby needs a new base backup.

What the model does. Disconnects cleanly and the pg_stat_replication projection correctly empties. But RC-2 leaves lagSec climbing to 300 s, lagBytes to 1.6 GiB and slot retention to 1.6 GiB, and four readouts print them unguarded.

Verdict: WRONG. Fix per RC-2.

Second, smaller gap. tickSegments() (src/sim/model.ts:1605) sets slotHold = 0 when rep.enabled is false, so pg_wal shrinks when the standby goes away. The comment three lines above says the opposite: "a slot nobody is reading pins WAL on the primary. That is how a replica takes down a primary's disk." The model can currently only show that with standbyASlowApply, never with a disconnected consumer — which is the case operators actually hit. The honest fix is to make the slot a distinct thing from the standby: keep slotHold alive while the standby is disconnected (that is what a slot does), and let standbyAEnabled = false mean "the standby is gone, the slot remains" — which is exactly the situation roadmap item 10's "drop the slot or add capacity" scenario needs.

Recovery: re-enabling resynchronises correctly (measured lagSec 0.22 after 120 s, with the "required WAL had been recycled" fast-forward path). Symmetric and right.

Fully covered by RC-6. Direction and down-sweep recovery are correct; only the scale and the units are wrong. Verdict: WRONG (magnitude / undisclosed unit distortion).

Real setting. hot_standby_feedback = on makes a standby report the xmin of its oldest running snapshot back to the primary through the walreceiver's status messages. The primary holds its xmin horizon back accordingly, so a long read on the standby blocks cleanup on the primary. It requires a standby, a replication connection, and therefore wal_level >= replica.

What the model does. setKnob() at src/sim/model.ts:3547 freezes the horizon unconditionally:

Measured — standbyAEnabled = false, walLevel = 'minimal', replication.connected = false:
  before standbyALongQuery=true : oldestSnapshotAge = 0.72 s
  after  standbyALongQuery=true : oldestSnapshotAge = 200.00 s   (and climbing)

A standby that provably cannot exist pins the primary's cleanup horizon. This is the same class of defect as the logical slot at wal_level = minimal: not a scaling artefact, a claim that cannot be true.

Verdict: WRONG.

Fix. Gate the pin on a live standby, and re-evaluate it every tick rather than only at setKnob time, because the standby can go away afterwards:

• In setKnob, treat the effective pin as K.longRunningXact || (K.standbyALongQuery && rep.enabled && rep.connected && K.walLevel !== 'minimal').
• Add the same check to tickReplication(), so that turning off standbyAEnabled or moving to wal_level = minimal while standbyALongQuery is on releases the horizon with the existing "xmin pin released" toast.
• When the knob is set with no standby present, say so rather than silently doing nothing: "hot_standby_feedback needs a connected standby — there is none." A knob that refuses with a reason teaches more than one that silently succeeds.

standbyALongQuery is also the thinnest-documented knob in the project: it has a hint in src/ui/content.ts:276 and nothing else — no pg_settings row, no entry in src/observability/paths.ts, no mention in either docs file, and no test. The hot_standby_feedback chapter at src/ui/docs-storage.ts:1671 does not list it in its own knobs: array.

Recovery: correct once gated — the horizon releases immediately and deadRemovable is restored for every relation (src/sim/model.ts:3578), then vacuum collects over the following minutes. The bloat that accumulated while pinned is legitimately not recovered instantly and must not be asserted to be.

A test asserting symmetry would be wrong for these:

Everything else must return: rates, gauges, occupancy, queue depths, horizons, active states, and lag.

Ordered by how well the consequence chain reads in-world.

1. lockContention — the most dramatic honest lever in the model. Pull it and 15 backends queue, 12 wait edges light up, throughput goes to zero; release it and everything resumes. Nothing to fix.
2. longRunningXact — the xmin horizon freezes visibly, vacuum workers report "0 removable (old snapshot)", bloat climbs, and releasing it produces a visible catch-up. The asymmetry is real and is the lesson.
3. standbyASlowApply — lag 0.37 s → 168 s → 0.43 s, with the flush/replay gap opening and closing in the world. Clean.
4. sharedBuffers — the buffer plaza physically resizes and the hit ratio moves 34 % → 100 %. Best-tested knob in the project (src/sim/knob-response.test.ts).
5. maxWalSize — WAL segment count and checkpoint cause both respond, and the "checkpoint triggered by max_wal_size, not by the timer" toast already fires.
6. autovacuumScaleFactor — a dial rather than a switch, but the response is monotone and the formula is PostgreSQL's.
7. checkpointCompletionTarget — the write phase visibly stretches and the I/O spike visibly flattens.
8. tps, 9. writeRatio, 10. updateRatio, 11. seqScanRatio — all correct, but they are workload dials rather than server settings, so a physical lever is a weaker metaphor. If they get handles, put them at the client district, not inside the machine.
9. timeScale, 13. paused — presentation controls; correct, but they belong to the camera rather than the city.

Ordered by how badly a newcomer would be misled.

1. walLevel — states four physically impossible facts simultaneously (RC-2). A visitor who reads "4.9 GiB of pg_wal held by a logical slot" at wal_level = minimal learns something that is not merely mis-scaled but backwards about how slots and WAL retention work.
2. autovacuum — the roadmap's named priority. Currently teaches that turning autovacuum off costs nothing and buys throughput. Four fixes required; RC-1 is the largest.
3. standbyALongQuery — a standby that cannot exist pins the primary's cleanup horizon. Cheap to fix, and it is a one-line class of error that a test can lock down permanently.
4. standbyAEnabled — a departed standby keeps reporting growing lag and growing slot retention. Same root cause as 1.
5. bgwriterEnabled — inverted throughput response. A lever that makes the database faster when you switch off a helper is the worst possible thing to put in a room a visitor can walk into.
6. fullPageWrites — advertises a 1.9× throughput reward for turning off corruption protection. Fixed by RC-1.
7. checkpointTimeout — half its trade-off is missing, and the shipped hint promises the missing half.
8. synchronousCommit — the on/local collapse contradicts remote_apply. Lower rank only because the direction of every step is right; the ladder is just missing a rung.
9. standbyANetworkLag — a fixed, undisclosed 6× on a number labelled in seconds. Direction and recovery are correct; only the units lie.
10. bgwriterLruMaxpages — inert above ~100. Least misleading of the ten, because a reader concludes "this does not matter much", which is nearly right; but the shipped documentation tells them to raise it, so it still fails the "documentation describes behaviour the app does not have" test.

RC-2 first: it is contained, it clears two knobs outright, and the correctly guarded observability projections already disagree with the panels, so the regression tests write themselves. Then RC-1, which is the largest single lever — it clears autovacuum, fullPageWrites, and the WAL-recovery tail behind tps and writeRatio, and it is a prerequisite for checkpointTimeout. Then RC-4 (small, clears bgwriterEnabled), RC-6 and RC-5 (both trivial), the standbyALongQuery gate (trivial), RC-3 and the synchronousCommit ladder (both structural but contained), and bgwriterLruMaxpages last.

The roadmap's "eleven of twenty-two" came from TASK-knobsweep.md. This audit disagrees in seven places:

Re-graded to CORRECT:

• tps and writeRatio — the earlier sweep marked both as failing on WAL magnitude and recovery. Isolated from autovacuum, both scale near-linearly (measured 52 → 385 → 2 600 → 6 800 KiB/s over 10 → 5000 tps; 0 → 176 → 358 → 526 → 685 KiB/s over writeRatio 0 → 1). Both defects were RC-1 wearing the knob's name.
• updateRatio — marked "recovery failed". It does recover, to exactly zero dead tuples, but it takes 1200 simulated seconds, which is longer than the earlier sweep's window. Slow, not broken; the slowness is RC-1.
• fullPageWrites kept its WRONG grade but for a different reason: the earlier sweep faulted the throughput reward, which is a symptom; the cause is that vacuum contributes 95 % of the full-page-image volume.

Added, previously passed:

• standbyALongQuery — passed as "same horizon pin as the local long transaction". It is, including when there is no standby.
• standbyAEnabled — passed on the grounds that the HUD shows —. Four other readouts do not.
• synchronousCommit — explicitly listed as a non-failure. The on ≡ local simplification is only defensible if remote_apply also collapses, and it does not.

Not reproduced: the earlier sweep's report that wal_buffers "repeatedly remains 100 % full for at least 20 simulated minutes". Measured occupancy peaked at 39 % and was usually near 0 %, because requestFlush() (src/sim/model.ts:1429) advances writeLsn to insertLsn on every call. What does persist after a load drop is the WAL rate, which stayed at 3–5 MiB/s for roughly 120 s and did not reach zero until ~300 s — entirely vacuum WAL (with autovacuum = false the same drop reaches 0 KiB/s within 15 s). The user-visible symptom is real; the named mechanism was not.

Measured with the same seeded direct-model method as the original audit. Each control was hard-stepped, observed for direction and magnitude, returned to its default, and checked for recovery. The retained-backup count has one legitimate asymmetry: expiration is deletion, so increasing retention later cannot resurrect a backup already expired.

The target sweep is intentionally asymmetric in direction: moving the target further back toward the backup needs less WAL and is faster. The open review finding changed the replay origin from the stop LSN to the start LSN. In the fixed 24-second probe, the old formula reported 42.21 MiB; the corrected model reports 77.49 MiB, adding the 35.28 MiB written during the copy that recovery must replay to make the backup consistent.

Measured with the same seeded direct-model method. standby_a retains the same standbyA* vocabulary that standby_b receives through standbyB*. Stored replica* preferences migrate to their standbyA* counterparts. Each sweep held standby_a connected and verified that its positions did not follow standby_b's failure. All three recover symmetrically: no deletion or other irreversible operation is hidden behind a toggle.

The physical-slot failure was also driven to the scaled disk boundary. With standby_a disconnected, 5,000 offered tps and 100% writes, its frozen slot retained 448.33 MiB and primary pg_wal reached the model's 512 MiB safety limit after 106.8 s. Writes then stopped; 66,209 represented writes were rejected over the next 5 s while reads and recovery work remained available. Reconnecting the standby and dropping load to 1 tps reduced retention to 115.9 KiB, primary pg_wal to 224 MiB, and reopened writes after 90 s. Production capacity and time-to-fill depend on WAL rate and filesystem size; real PostgreSQL PANICs when the filesystem fills.

Measured with the same seeded direct-model method. The failover drill used 2,000 offered tps, 100% writes and synchronous_commit = local, because a standby named for synchronous commit would correctly reduce this particular loss window to zero. pg_rewind checks prerequisites for 2.0 teaching seconds before it starts copying; a failed preflight is therefore visibly an operation, not an instantaneous boolean response.

The promotion itself was swept at two different one-way lags under the same workload. At 40 ms, timeline 2 forked at 0/20B4FE66; the former primary ended at 0/20BC016D, so 459,527 bytes and 171 committed write transactions were lost. At 400 ms, the fork was 0/2055AA03 against that same former-primary end: 6,707,050 bytes and 2,622 transactions were lost. The direction is strict for both units. A planned switchover from the 300 ms case waited 2.67 s for the standby and recorded exactly zero bytes and zero transactions lost. Sixty seconds after that handover, the demoted primary had advanced from LSN 551,833,503 to 724,759,874 — 172,926,371 bytes — and matched the current leader instead of freezing.

The replacement control was swept from a freshly seeded model for 5.0 teaching seconds per partition, longer than the compressed 4.0 s lease TTL. The baseline was Raft term 1 / commit 14 after warm-up. “Grant” below means a leader-key value with a valid lease, not a stale applied value on an isolated etcd member. The city models consensus first: a majority is the mechanism Raft uses to commit the lease expiry and compare-and-swap, and no minority operation is treated as a vote that merely lost.

The deterministic candidate choice, shared compressed HA-cycle clock, 4.0 s TTL, and 1.0 s renewal interval are teaching scale. Production ttl, loop_wait, retry behavior, Raft election timeouts, candidate scoring, and network timing depend on Patroni and etcd configuration.

The three operator situations added no further Knobs fields, so that addendum ended at verdict 35; the work_mem addendum below adds verdict 36. Adding storage, dropping a replication slot, terminating a backend, promoting a named node, rebuilding a standby and running pg_rewind are operations with consequences, not configuration policy. They therefore use the existing model state and operation APIs rather than disguising one-shot work as sliders.

All six branches were driven through SimApi at 1/30 s with the seeded model. The write rate in the slot case is deliberately scaled so the primary reaches a decision point in under three simulated minutes; the scenario rail discloses that scale.

These are not symmetric “play styles.” In the staged slot incident, adding capacity preserves a viable standby for a 512 MiB cost, while dropping the slot trades that cost for an 8.36 GiB rebuild. In the xmin incident, pg_stat_activity shows that the holder is idle, so waiting protects no running query. In the failover incident, standby_a has the later durable LSN and synchronous acknowledgement history; choosing standby_b discards acknowledged commits and invalidates standby_a as a follower. This follows the PostgreSQL manual's High Availability timeline rules and the minimum-recovery-point check in checkTimeLineSwitch() / rescanLatestTimeLine(); Patroni makes the same rewind-or-reinitialise decision for every node ahead of the selected leader.

The new control is a real modeled consequence but deliberately not a planner control. Both sides of the sweep requested the same seeded aggregate against sessions; its preselected template was byte-for-byte the same five labels: Parallel Seq Scan → Partial HashAggregate → Sort → Gather Merge → Finalize GroupAggregate. Only the executor-node method annotations and consequences changed.

The per-node sum is part of the regression: the 2 MiB run exposed 6 MiB of nominal allowance across its two eligible nodes, already greater than the knob itself. Hash nodes use work_mem × hash_mem_multiplier; the default multiplier has been 2.0 since PostgreSQL 15. Concurrent backends repeat those allowances. The sums are nominal limits, not a claim that every executor node peaks at the same instant.

Scope is intentionally smaller than PostgreSQL. The city has no join nodes, hash-join spill, parallel worker execution, or cost-based plan selection. It models only fixed Sort and HashAggregate working sets and never lets work_mem select a plan. The cumulative model counters project as pg_stat_database.temp_files and temp_bytes; the production investigation path also names log_temp_files. One modeled spilling node creates one modeled temp file per represented statement, while PostgreSQL can use multiple files and passes.

Everything above was measured with a temporary probe under test/, driving createSim() with a stub bus and stepping update(1/30) — no browser, seeded RNG, deterministic. Warm-up was 300–400 simulated seconds before every reading, with the observation window stated per measurement. The probe was deleted; the worthwhile parts to keep permanently, as CI regression tests, are:

1. wal_level = minimal ⇒ wal.segmentCount × 16 MiB <= max_wal_size × 2 and logical slot retention is zero, after 600 simulated seconds.
2. standbyAEnabled = false ⇒ standby_a is disconnected, its durable LSN is frozen, its slot is inactive, and retained WAL grows as the primary advances.
3. standbyALongQuery = true with standbyAEnabled = false ⇒ oldestSnapshotAge stays bounded.
4. autovacuum = true ⇒ WAL rate is within 1.5× of the autovacuum = false rate for the same workload.
5. bgwriterEnabled = true ⇒ dirtyEvictions falls and achieved tps does not.
6. bgwriter_lru_maxpages 100 vs 400 ⇒ measurably different cleanedTotal under a churning workload.
7. checkpoint_timeout 15 s vs 120 s ⇒ full-page-image share falls by at least a third.
8. wal.bufferCapacity === clamp(shared_buffers / 32, 64 KiB, 16 MiB).
9. synchronous_commit commit-wait ladder is strictly increasing across off < local < on < remote_apply with a standby connected.
10. Every knob: set, warm, unset, warm — assert every rate and gauge returns to within tolerance, and assert relation pages do not.