The PostgreSQL 17 cap tests expect the managed-conf behavior: the old value in darling-managed.conf is capped, and an operator's out-of-range line refuses the start

[erikdarlingdata]

Why

Postgres17Store_WithTheOldCapInItsConf_StartsThroughTheBootstrap_Gated simulated "a build before #3909" by
appending a bare, unmarked maintenance_work_mem = 2048MB line to postgresql.conf after the first
EnsureRunningAsync() call. That first call already migrates the store's conf to the one included
darling-managed.conf file, so the appended line landed below the include -- the exact position an
operator's own line occupies, per the migration classifier's own rule.

History confirms this: every write of maintenance_work_mem this service has ever made carries its own
marker, never a bare line.

History: how maintenance_work_mem was written

• 16cca9934 2026-07-09, "Darling managed Postgres: derive a memory-tuning conf block from host RAM" --
  inside marker v3 (BuildMemorySizingConfAppend).
• f4c86ffa3 2026-07-27, "Raise managed store maintenance_work_mem to the measured compression floor
  (maintenance_work_mem formula lands too low for compression throughput: +70% measured from raising it, plateaus by 1.5 GB #1777)" -- inside marker v7 (the compression-memory override).
• 922caa68d 2026-07-27, "Record the incremental-allocation constraint the small-host landings rest on
  (maintenance_work_mem formula lands too low for compression throughput: +70% measured from raising it, plateaus by 1.5 GB #1777)" -- comment-only, no write.
• 714af66f8 2026-09-03, "Re-derive managed-store Postgres sizing when the host changes (Fixes Managed-store memory sizing never re-derives after a host resize (effective_cache_size stale at 75% of the OLD RAM) #2845)" --
  inside marker v8 (BuildHardwareSizingConfAppend).
• f0417452 2026-09-03, "Review: v8 must not act on a non-authoritative RAM reading" -- guards v8's own
  append, no new write.
• e507aa2d1 2026-09-22, "A store still on PostgreSQL 17 no longer fails to start on a 40 GB+ host (Managed store writes maintenance_work_mem = 2048MB, one kB over PostgreSQL 17's Windows maximum: a 17.x store on a 40 GB+ host cannot restart #3909)
  (A store still on PostgreSQL 17 no longer fails to start on a 40 GB+ host (#3909) #3917)" -- inside marker v14 (BuildLegacyMaintenanceWorkMemCapConfAppend), the cap block itself.
• 1ae41290a / 6dbb22a50 2026-09-26 (Managed store sizing: make the derivation platform-aware (Windows 487 cap only on Windows, Linux cgroup limits, commit headroom) and write it to one service-owned config file instead of appended blocks #4215/Move the managed store's settings into one included file, darling-managed.conf (#4215) #4336), "Move the managed store's settings into one included
  file, darling-managed.conf" -- confines the v14 heal to a Legacy conf and moves the setting into the
  rendered darling-managed.conf; no bare write introduced.
• 12893bc5 2026-09-26, "A carried maintenance_work_mem is capped for PostgreSQL 17 and earlier when the managed
  settings move (A carried maintenance_work_mem is capped for PostgreSQL 17 and earlier when the managed settings move (#4336) #4444)" -- the one-time migration (ManagedConfMigrationRunner.RunStepA) caps a carried value as it
  writes it into the rendered darling-managed.conf; no bare write to postgresql.conf.
• 88e69c88 / 421c57cc 2026-09-25 (Store host visibility: a cross-platform host profile, a --check-settings verb, and a get_store_host read, so "is this store sized right" has an answer without shell access #4214), the store host profile and --check-settings -- compare the store's
  live setting with the value derived for the host; no write.
• 7b19082d 2026-09-18, cbb00d9a / 6d629ace 2026-09-20 -- the PostgreSQL-target analysis reads a monitored
  server's own settings (PgTarget*); it never writes the store's conf.
• Every other hit for maintenance_work_mem in service code (DarlingStoreHostProfile.cs,
  ManagedConfMigration.cs, ManagedConfMigrationRunner.cs) is a reader/classifier/advisory, not a
  postgresql.conf write.

No commit ever wrote maintenance_work_mem bare below the include. The test's setup line was never a shape
this product produces -- confirming this is a stale test (S), not a product defect.

What changes

Test-only, in Darling/Darling.Tests/DarlingManagedPostgresTests.cs. No product code changed.

1. Postgres17Store_WithTheOldCapInItsConf_StartsThroughTheBootstrap_Gated is renamed and reworked to
   Postgres17Store_WithTheOldValueInItsManagedConf_StartsWithTheCap_Gated: after the first start, it
   replaces the one maintenance_work_mem assignment inside the rendered darling-managed.conf with the
   old, uncapped 2048MB -- the shape the managed file itself can carry -- then recomputes the header's
   # body-sha256= line over the edited body, the same way the product's own write path would, so the file
   still reads as the product's own render (ManagedConfFile.IsHandEdited is asserted false on it) rather
   than an operator hand edit. A hand edit is never overwritten and would only ever reach the last-good
   fallback in EnsureManagedConfReadyAsync, never the re-render this fact means to pin. It then asserts
   the second start:

   • took the re-render path, not the last-good fallback: second.LastManagedConfWriteResult shows
     Written: true, HandEdited: false, and second.LastStartUsedLastGoodManagedConf is false;
   • leaves exactly one maintenance_work_mem assignment in darling-managed.conf, and it isn't the old
     2048MB;
   • runs the server on exactly the value the re-render wrote (read back from the file), and that value is at
     or under the 2047 MB cap.

   The rendered value depends on the host's RAM. The first test-only run on this branch expected the cap
   itself and failed on a CI runner whose RAM renders 1536 MB, under the cap, so the cap never engaged. The
   product has no seam to pin the RAM input, and adding one would be a product change, so the fact now
   asserts the host's own render instead. ManagedConfFileTests pins the cap arithmetic for any RAM without a
   server.

   • leaves postgresql.conf carrying the include and no maintenance_work_mem line of its own.

2. New fact Postgres17Store_OperatorLineBelowIncludeOutOfRange_RefusesToStartNamingTheFix_Gated: appends
   a bare, out-of-range line below the include (the honest shape of an operator edit) and asserts the second
   start throws InvalidOperationException naming maintenance_work_mem and the fix instruction from
   BuildManagedConfValidationFailureMessage, then that the store is not left running (stop is a safe
   no-op, and a connection attempt fails). Its doc comment no longer claims this data directory has never
   had a last-good file -- the first start above already succeeded, so it saved one
   (DarlingManagedPostgres.SaveLastGoodManagedConf), and the test now asserts that file exists before the
   second start. The fallback is tried and still refused, because the rejected line lives in
   postgresql.conf below the include, not in darling-managed.conf: restoring the last-good managed file
   leaves the operator's own line in place untouched.

Both facts stay gated on DARLING_TEST_PGRUNTIME_OLD, Windows, and pg_ctl.exe present, same as before.

Both facts read conf lines as ACTIVE assignments through the product's own parser (DarlingManagedPostgres.ParseConfText, via a small ActiveValues helper), never as raw substrings: initdb writes commented sample lines such as #maintenance_work_mem = 64MB into postgresql.conf, and a substring check on the key name matches them. The non-gated fact ActiveValues_SkipsInitdbsCommentedSampleLines_AndCountsAnOperatorLine pins that with lines copied from PostgreSQL 17's postgresql.conf.sample.

Gated tests that must pass

These run only on a test-only nightly.yml run (publish=false); PR CI doesn't run them.

• Postgres17Store_WithTheOldValueInItsManagedConf_StartsWithTheCap_Gated
• Postgres17Store_OperatorLineBelowIncludeOutOfRange_RefusesToStartNamingTheFix_Gated
• Postgres17StoreWithTheOldCap_StartsAfterTheHeal_Gated (unchanged; must stay green)

Test plan

• dotnet build Darling/Darling.Tests/Darling.Tests.csproj -c Release -p:EnableWindowsTargeting=true: 0
  warnings, 0 errors.
• dotnet build Lite.Tests/Lite.Tests.csproj -p:EnableWindowsTargeting=true: 0 warnings, 0 errors.
• In-process run on macOS (DarlingManagedPostgresTests, no DARLING_TEST_PGRUNTIME_OLD set): both new
  gated facts SKIP for the expected reason; 181 total, 5 failed -- all five are pre-existing macOS
  path-separator failures unrelated to this change (ResolveDataDirectory_TrimsATrailingSeparator,
  PathConventions_DefaultDataDirectory_AndCredentialBesideIt, RoleCredentialPaths_BesideTheDataDirectory,
  McpCredentialPath_BesideTheDataDirectory_AndDistinctFile,
  EnsureConfAppended_ThreeExistingV8Blocks_CollapseToOneOnTheNextHeal), none in the file this PR touches.
• DocCommentHygieneTests: 77/77 green.
• Two fast, non-gated pins already on dev cover fact 1's cap from two different angles, and are named
  here (not added new) for what each one actually pins:
  • ManagedConfFileTests.RenderBody_CarriesEveryManagedConfMarkersOwnedKeys (its class summary, ~line 387)
    pins the RENDER itself: DeriveMemorySettings's formula caps maintenance_work_mem at
    MaintenanceWorkMemCapMb for ANY RAM size a fresh render can derive -- this is the per-start render
    fact 1 exercises through the product's own bootstrap.
  • ManagedConfMigrationRunnerTests.RunStepA_CarriedMaintenanceWorkMemOver2047_Postgres17_Caps pins the
    one-time Move the managed store's settings into one included file, darling-managed.conf (#4215) #4336 Step A migration's carry-over instead: a pre-existing, over-limit value already on disk
    from before the render's own cap existed, capped once when Step A runs.
    Both ran green (33/33 in ManagedConfFileTests; the Step A class also green).
• The two gated facts themselves cannot run on macOS (Windows-only bundled runtime) and both SKIP for the
  expected reason (no DARLING_TEST_PGRUNTIME_OLD set); they are named above for the nightly workflow
  run to confirm.

Total

• DarlingManagedPostgresTests: Total: 181, Errors: 0, Failed: 5, Skipped: 10, Not Run: 0 (the 5 failures
  are the same pre-existing macOS path-separator failures listed above, unrelated to this change and present
  identically with this change reverted).
• ManagedConfFileTests: Total: 33, Errors: 0, Failed: 0, Skipped: 0, Not Run: 0.
• DocCommentHygieneTests: Total: 77, Errors: 0, Failed: 0, Skipped: 0, Not Run: 0.

CHANGELOG entry

None: a test-only change. The product's managed-conf behavior on PostgreSQL 17 was already correct; only the test's out-of-date expectation changes.

Refs

Refs #4336 (the commit that moved settings into darling-managed.conf and made the old test's setup line an
operator line), #3909 (why the cap exists at all), #4405 (lines below the include are the operator's; across a major upgrade they are carried and probed), #4444 (a different, unrelated fix that this
PR does not touch or depend on).