Repository navigation
Store-object convergence re-runs hourly on a plain-PostgreSQL store too, not only at restart (#3913) - #3932
Merged
Conversation
… hourly pass walks the steps that do not need TimescaleDB (#3913) The hourly store-maintenance tick ran the convergence pass only inside its _timescaleAvailable gate, so on a store without TimescaleDB, a supported configuration, nothing re-ran between restarts: a dropped baseline fallback view, a retired baseline relation's time-dependent drop, the store's statement statistics (an extension a DBA creates by hand, a grant for a role provisioned later) and the composer's covering indexes all waited for the next start. - ConvergeStoreObjectsAsync takes timescaleAvailable and has ONE filter: without TimescaleDB it skips exactly the stages the start path runs inside its own TimescaleDB gate (NeedsTimescale: Timescale, TimescaleAfterRepairLaunch), and runs every other step, as the start path does. - The tick's else branch runs it on a plain-PostgreSQL store. The gated block's call and the four-tenant order are untouched. - The cadence claims #3899 added (a plain-PostgreSQL store waits for its next start) are corrected in the tool's remedies, the step comment, StoreStatementStats, provision-roles.sql and the README. Tests: the convergence pin now asserts the one filter and nothing else, NeedsTimescale is pinned per stage, and the tick and retention pins are unchanged and green. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018Z4T51J4E6L8fjriPHpsif
erikdarlingdata
enabled auto-merge (squash)
September 22, 2026 23:31
This was referenced Sep 22, 2026
erikdarlingdata
added a commit
that referenced
this pull request
Sep 23, 2026
…3920, #3927, #3931, #3932, #3940, #3942, #3946, #3947, #3950, #3952, #3955, #3956, #3957, #3964, #3965, #3966, #3968, #3972, #3975, #3979, #3980, #3981, #3983, #3984, #3985) (#3989) The wave's fix PRs deliberately carried no CHANGELOG edits (parallel-agent hot-spot protocol); each agent reported its entry and this commit lands them together, byte-verified against origin/dev. Claude-Session: https://claude.ai/code/session_01GdmA4ND1wLSqA91ax1m4xv Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
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
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.
Closes #3913.
CHANGELOG: this PR carries no CHANGELOG edit. Its entry lands with the batched splice.
Why
#3817 made store-object convergence re-run hourly, so a failed ensure heals within the hour. That hourly pass sat inside the tick's
_timescaleAvailablegate, so on a store without TimescaleDB, a supported configuration, nothing re-ran between restarts. The affected steps are:Each waited for the next restart.
What changes
ConvergeStoreObjectsAsynctakestimescaleAvailableand has one filter. Without TimescaleDB it skips exactly the stages the start path runs inside its own TimescaleDB gate (NeedsTimescale:Timescale,TimescaleAfterRepairLaunch). Every other step runs, as it does at start.elsebranch that runs the pass on a plain-PostgreSQL store. The gated block, its four-tenant order and the#3575phase argument are untouched; none of that applies to a store with no policy jobs.get_store_query_stats' remedies, the step comment,StoreStatementStats,provision-roles.sqland the README.Test plan
NeedsTimescaleis pinned per stage.TimescaleAvailabilityReprobeTests,RetentionReevaluationTests) are unchanged and green: one stamp, one gated convergence call, same order.Darling.Testsafter rebasing onto The store's statement text and store log keep no literal: a one-pass SQL lexer, an allowlist reader, masking for every retained log class, and stricter conf parsing (#3899) #3920: 12,487 run. The only failures are the three runtime-version pins my local rig (18.4) can't meet against dev's 18.6 pin; CI builds the pinned runtime.🤖 Generated with Claude Code
https://claude.ai/code/session_018Z4T51J4E6L8fjriPHpsif