fix(postgresconfig): render baseline after ref so operator sizing wins - #635
Open
GuptaManan100 wants to merge 4 commits into
Open
fix(postgresconfig): render baseline after ref so operator sizing wins#635GuptaManan100 wants to merge 4 commits into
GuptaManan100 wants to merge 4 commits into
Conversation
Render() appended layers baseline -> ref -> inline, so the deprecated PostgresConfigRef overrode the operator's resource-derived baseline (PostgreSQL applies later assignments last-write-wins). The ref is opaque raw text: if it contains an `include` directive, PostgreSQL transitively pulls in an external file the operator never sees, silently overriding carefully sized values (shared_buffers, effective_cache_size, max_slot_wal_keep_size, ...) with whatever is baked into that file. Render the baseline AFTER the ref (ref -> baseline -> inline) so the operator's own sizing math always wins over the deprecated ref, while inline spec.postgresConfig remains the single explicit override. This inverts the documented baseline-vs-ref precedence; ref-vs-inline is unchanged (inline still last). Add a unit repro (TestBaselineWinsOverRefForResourceDerivedKeys) and update the two tests that pinned the old ordering (render_test.go, postgres_config_test.go). Signed-off-by: GuptaManan100 <guptamanan100@gmail.com>
Add TestBaselineWinsOverRef: create a shard with a postgresConfigRef that sets a resource-derived key (effective_cache_size) to a value the operator's sizing would never produce, and no inline override. It asserts the effective value is the operator's sized baseline (384MB at a 512Mi pool limit), not the ref's 999MB. This fails against the pre-fix operator (ref wins) and passes after (baseline wins). It also asserts a genuinely baseline-absent ref-only key (seq_page_cost) still applies, proving the ref is layered under the baseline rather than discarded. Fix the existing "legacy postgresConfigRef is still honored" subtest, which used random_page_cost as its ref-only probe. random_page_cost is set by the operator baseline (1.1), so with the baseline now winning over the ref the old assertion (2.5) no longer holds; switch it to seq_page_cost, which the baseline does not set. Signed-off-by: GuptaManan100 <guptamanan100@gmail.com>
This comment has been minimized.
This comment has been minimized.
…baseline-over-ref-precedence
This comment has been minimized.
This comment has been minimized.
Signed-off-by: GuptaManan100 <guptamanan100@gmail.com>
🔬 Go Test Coverage ReportSummary
Status✅ PASS DetailShow New Coverage |
GuptaManan100
marked this pull request as ready for review
September 10, 2026 15:54
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Render()appended config layersbaseline → ref → inline, so the deprecatedPostgresConfigRefoverrode the operator's resource-derived baseline (PostgreSQL applies later assignments last-write-wins).includedirective, PostgreSQL transitively pulls in an external file the operator never sees, silently overriding carefully sized values (shared_buffers,effective_cache_size,max_slot_wal_keep_size, …) with whatever is baked into that file.ref → baseline → inlineso the operator's own sizing math always wins over the deprecated ref, while inlinespec.postgresConfigremains the single explicit override.Problem
The operator treats
refContentas opaque text appended after its baseline "so the user's override wins." But when that text is e.g.include = '/etc/postgresql/postgresql.conf', Postgres expands it at parse time into a whole external file the operator has zero visibility into — and that file can redefine the operator's resource-derived GUCs, silently replacing them with generic image defaults. Symptom: the operator's sizing looks correct in isolation and in inline-only tests, yet a real project's baseline values never take effect.Solution
Render the baseline after the ref:
ref → baseline → inline. The operator's resource-derived values (and anything the baseline sets) now win over the ref and anything it transitively includes; inlinespec.postgresConfigstays last and remains the one intended way to deviate from the baseline.This is a deliberate precedence semantics change for the deprecated ref (baseline-vs-ref inverts).
ref-vs-inlineis unchanged — inline still wins.