Heal the v8 sizing block on stores resized before #4225 (#4207)

[erikdarlingdata]

Closes #4207.

Why

#4225 fixed the v8 hardware-sizing block's append-not-replace bug (collapsing duplicate blocks to one) and put work_mem back into the formula. Its heal only re-runs when ShouldAppendHardwareSizing sees the newest fingerprint in the conf differ from the current hardware and hypertable count. A store whose hardware has not moved since its last v8 write has no fingerprint change left to trigger on, so upgrading it past #4225 changed nothing: its conf still held its old duplicate v8 blocks, none of them carrying work_mem, so the store's actually-live work_mem value kept coming from the frozen v3 block instead.

This is exactly what issuecomment-5837990283 on #4207 reported after #4225 shipped: --check-settings still exits 3 (work_mem 31MB / derived 62MB: stale-after-hardware-change), and postgresql.conf still held three v8 blocks plus the v3 block's stale work_mem = 31MB. The store's hardware had not changed since its last v8 write, so #4225's own fix never ran on it.

What changes

• ShouldAppendHardwareSizing (DarlingManagedPostgres.cs) now also heals, still only with an authoritative RAM reading, when either of two new conditions holds: the conf carries more than one v8 block, or the newest v8 block's rendered content (CRLF-normalised) does not match what this build would write for the current inputs. The second condition is what catches a block whose fingerprint is current but whose formula is stale, which is the field case above — the fingerprint only encodes RAM and hypertable count, never the code version that turned them into settings.
• New NewestHardwareSizingBlockIsCurrent does the content comparison, comparing only the LAST v8 block's span against the text BuildHardwareSizingConfAppend would produce right now, with \r\n normalised to \n on both sides (the file can be CRLF; the freshly-rendered text is always LF).
• The call site now builds the candidate append text before the decision (the content-comparison condition needs it to decide, not just to write), and logs which of the three reasons fired — fingerprint changed, duplicate blocks found, or stale content — at Information, in addition to the existing Appended/Rewrote and collapsed-copies detail.
• postgresql.auto.conf is still never touched by any of this, so ALTER SYSTEM values keep winning exactly as before.
• In-lane: fixed an xUnit2013 analyzer warning the new tests introduced (Assert.Equal(1, x.Count) to Assert.Single(x)) to keep the build at 0 warnings.

Lite has no equivalent: it does not manage its own PostgreSQL install, so there is nothing to mirror there.

CHANGELOG entry

SECTION: Fixed
ENTRY:

• Heal the Postgres v8 hardware-sizing block on stores resized before the DO NOT MERGE (managed store sizing): re-derive work_mem after a resize and keep one v8 block (#4207) #4225 fix shipped ([Heal the v8 sizing block on stores resized before #4225 (#4207) #4342]) - A managed store whose hardware had not changed since its last hardware-sizing rewrite never re-triggered the heal, so a store that already carried duplicate sizing blocks, or a block written before work_mem rejoined the formula, stayed on stale settings even after upgrading past the earlier fix. The heal now also runs when the conf carries more than one sizing block, or when the newest block's content no longer matches what the current build would write.
  REF:
  [Heal the v8 sizing block on stores resized before #4225 (#4207) #4342]: Heal the v8 sizing block on stores resized before #4225 (#4207) #4342

Test plan

• dotnet build Darling/Darling.Tests/Darling.Tests.csproj — 0 Warning(s), 0 Error(s).
• DarlingManagedPostgresTests alone — 170 tests, 0 failed, 6 skipped (gated live tests, no rig env vars in this pass).
• *ManagedPostgres*, *CheckSettings*, *StoreHostProfile*, StartupCommandTimeoutTests, DocCommentHygiene* — 317 tests, 0 failed.
• New live test ExistingStore_HealsPreFixV8Blocks_OnNextStart_Gated alone, with DARLING_TEST_PGRUNTIME pointed at a freshly extracted runtime: provisions a real store, strips work_mem from its own real v8 block and triples it (reproducing the field shape without needing a specific RAM figure), restarts, and confirms SHOW work_mem on the live server matches the derived value — passed. Rig runtime directory removed afterward.
• Proved the regression once: ShouldAppendHardwareSizing_FieldCase_OldFingerprintOnlyPredicate_WouldWronglySkip reproduces Managed-store memory sizing never re-derives after a host resize (effective_cache_size stale at 75% of the OLD RAM) #2845's original single-condition expression inline (the function's signature changed, so the old expression can no longer be called directly) and asserts it returns false — "nothing to do" — on the exact fixture the sibling test proves needs healing.
• After git merge origin/dev (clean, no conflicts) and a rebuild: full Darling.Tests suite once — 14228 total, 0 errors, 0 failed, 784 skipped, 1 "Not Run". The "Not Run" count is a pre-existing runner artifact with no name or reason logged against it; Errors and Failed are both 0, and nothing in this PR's diff touches test discovery or collection machinery, so I did not chase it further.
• Lite.Tests — not run; this PR does not touch Lite, which has no managed-PostgreSQL install of its own to heal.
• Full suite with DARLING_TEST_PG/DARLING_TEST_PGRUNTIME set (every other live-gated test) — not run; out of scope for this lane, which was asked only to add the one new live test "if cheap."

🤖 Generated with Claude Code

https://claude.ai/code/session_01TszxYhJJbTEh4LrZ56NYo3