The bundled store authors its memory knobs from the box but leaves max_wal_size at PostgreSQL's 1 GB default — derive it from disk headroom (≤16 GB) in the same versioned, heal-on-start block #3802

The bundled store's config authoring sizes memory from the box and leaves max_wal_size at PostgreSQL's 1 GB default

DarlingManagedPostgres appends marker-guarded, versioned blocks to the managed cluster's postgresql.conf and re-derives them on every service-owned start — shared_buffers, effective_cache_size, work_mem, maintenance_work_mem, max_worker_processes, all from total physical memory (DeriveMemorySettings, DarlingManagedPostgres.cs:688; the v5/v6 heal discipline re-states a knob so a resized box heals up or down on its next start). max_wal_size is not among them, so every managed store runs PostgreSQL's default 1 GB.

Measured consequence on the largest production store, 2026-09-20 15:20–15:40Z (the #3745 exhibit): one continuous-aggregate refresh wrote 8.3 M rows in a single transaction, blew through max_wal_size mid-checkpoint, forced a second WAL-triggered checkpoint (199 s), and every heavy read on the store starved for four minutes — the fleet overview cancelled twice, four alert reads cancelled, a parallel worker failed to spawn (could not reserve shared memory region). The maintainer authorised an out-of-band max_wal_size = 16GB on all three stores (reload-only, verified), and ruled the product should author it: "that should also be part of our standard postgres config, as long as the box can afford it. so dynamic i guess."

Fix shape — derived, not a constant (the house theme)

A new versioned block beside the memory ones, same marker + heal discipline, re-derived each start:

• max_wal_size = min(16 GB, max(1 GB, free_disk_on_the_data_volume / 8)) — the data directory's volume, read at ensure-time (DriveInfo on the cluster's data path; the composer already knows the path). A shrinking disk pulls it back down on the next start; a box that cannot afford it gets the default, stated in the log line.
• min_wal_size proportional (a quarter of max_wal_size, floored at PostgreSQL's 80 MB default), so WAL recycling keeps pace.
• checkpoint_completion_target = 0.9 if not already authored (spreads the write; the default is 0.9 on PG ≥ 14 — verify and skip if so).
• Log one INFORMATION line per start with the derived values and the free-disk figure they came from (the self-proving shape: a re-derivation that changes nothing still says so).

Interplay to state on the block's doc comment: a larger max_wal_size lengthens crash recovery on the bundled store (more WAL to replay), which is the price of fewer forced checkpoints; the ceiling of 16 GB is the maintainer's measured choice for a store class writing ~8 M-row materializations, not a universal one. The block must NOT fight an operator's ALTER SYSTEM — postgresql.auto.conf wins over postgresql.conf by PostgreSQL's own precedence (the existing lc_messages note at :253–254 already documents this); the ensure logs when an auto.conf override is present rather than overriding it.

Scope

Darling managed-store only (Lite has no PostgreSQL). The unit-testable seam is the existing Build*ConfAppend(long totalPhysicalMemoryBytes) pattern — add long freeDiskBytes and pin the formula at the boundaries (tiny disk → default; huge disk → 16 GB cap; the heal-down case). No rung. The out-of-band 16 GB on the three production stores is ALTER SYSTEM-class or postgresql.conf-edited — the lane must read WHICH, because if it is in postgresql.auto.conf the new block will be shadowed there by design and the log line must say so.