Repository navigation
Darling's deadlock maintenance logs a line when a stage recovers after a failed pass (#5634) - #5637
Merged
Merged
Conversation
…r a failed pass (#5634) A re-mask stage that failed one or more passes and then succeeds now logs one information line naming the stage and how many passes had failed. A clean pass with no earlier failure logs nothing new.
Adds the 3.10.0 Fixed entry for the recovery log line.
erikdarlingdata
marked this pull request as ready for review
October 9, 2026 14:34
erikdarlingdata
enabled auto-merge (squash)
October 9, 2026 14:36
erikdarlingdata
disabled auto-merge
October 9, 2026 15:03
erikdarlingdata
enabled auto-merge (squash)
October 9, 2026 15:04
erikdarlingdata
added a commit
that referenced
this pull request
Oct 9, 2026
erikdarlingdata
added a commit
that referenced
this pull request
Oct 9, 2026
Adds the changelog entries for #5626 and #5628 to the 3.10.0 index and to docs/changelog/3.10.md. The #5628 entry cites its own PR. The 3.10.0 date is now 2026-10-09. A second Important entry covers the Windows upgrade stop for installs that ordinary users can write to. The Important note now names store migrations V158 through V173, as dev is at schema 173. The README gains the shared time range picker, the text column filters and Lite's DuckDB memory limit setting. The branch merges dev, which brings in the entries for #5636 and #5637, and every entry from both sides is kept. The archive split and census run last. The 3.10.0 census row is 295 entries, and verify and roundtrip both pass. No duplicate section headers and no missing reference links were found in the 3.10.0 entries. The last changelog splice for 3.10.0, and the README sync.
Merged
12 of 13 tasks
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.
Darling's hourly PostgreSQL deadlock maintenance logs a warning when one of its stages fails a pass, but logged nothing when a later pass of that stage succeeded. An operator who read the warning had no line saying the stage came back. A stage that succeeds after one or more failed passes now logs one information line that names the stage and how many passes had failed. A clean pass with no earlier failure logs nothing new, and the back-off, skip and progress logic are unchanged.
SECTION: Fixed
ENTRY: - Darling's deadlock maintenance logs a line when a stage recovers after a failed pass ([#5637]) - The hourly PostgreSQL deadlock maintenance logged a warning each time one of its stages failed a pass, but nothing when a later pass succeeded, so the last line an operator saw for the stage was the failure. A stage that succeeds after one or more failed passes now logs one information line naming the stage and how many passes had failed. A clean pass with no earlier failure logs nothing new.
Details
Darling/PerformanceMonitor.Darling.Service/PgDeadlockRemask.cs, where a clean page resetsConsecutiveFailures: when the count is above 0, oneLogInformationline says the stage recovered. It also says how many earlier passes in a row had failed. The line carries the stage name and the count only, never row content.Darling/Darling.Tests/PgDeadlockRemaskTests.cs: two live tests on a local test PostgreSQL.AStageThatRecoversAfterFailures_LogsOneRecoveryLine_WithTheFailureCountfails the alert stage twice by renaming its table away. It then restores the table and expects exactly one recovery line for that stage with the count 2. The two other alert-table stages fail and recover on their own, and each is checked to log at most one line.ACleanPassWithNoEarlierFailure_LogsNoRecoveryLineruns the stages with no failure and expects no recovery line. The test logger now also keeps the information lines.CHANGELOG.mdanddocs/changelog/3.10.mdcarry the entry under 3.10.0 Fixed.Tests
Darling.Tests on a local PostgreSQL:
PgDeadlockRemaskTestsTotal 26, Failed 0. Then as Total/Failed:*Census*500/0,*Ratchet*15/0,*Hygiene*90/0,*Scrub*123/0,*Guard*365/0,*DocComment*78/0,Stage=Guard1474/0. 0 build warnings.Fixes #5634