Cap the viewer's store pool + document the postgres.exe process anatomy (round-4 field follow-up) - #1566
Merged
Conversation
Round-4 field check falsified the "~24 backends" claim as stated: process count oscillated 17-44 with checkpoint/catch-up waves. Two things were true at once: - The peaks are TimescaleDB background POLICY WORKERS (we size timescaledb.max_background_workers to hypertables+2 ~= 38; every running compression/retention job is its own postgres.exe), not client backends - they surge with policy waves and recede, with OS free memory rock-stable throughout (field-confirmed). - The claim was also genuinely incomplete: the viewer built its connection string independently and rode Npgsql's default pool of 100. Now MaxPoolSize=10 (read-only UI seat, 30/60s timers). README troubleshooting gains the anatomy note + the pg_stat_activity GROUP BY backend_type decomposition query + the working-set double-counting reminder. Darling 2170/0 (Release, full). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This was referenced Sep 4, 2026
Merged
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
Round-4 verification correctly reported that the #1559 "~24 backends" claim didn't hold as stated: postgres.exe oscillated 17→44 with checkpoint/catch-up waves, matching round-3 peaks. The claim was wrong in framing and incomplete in coverage:
timescaledb.max_background_workersto hypertables+2 (≈38) and every running compression/retention job is its own process. They surge during policy waves and recede; the field box's OS free memory was stable (~11.9GB) through every swing, and the checkpointer stayed under its ~1GB ceiling.ViewerSettings.cs) and rode Npgsql's default of 100. NowMaxPoolSize = 10.README troubleshooting gains the anatomy note: the three process populations, the
SELECT backend_type, count(*) FROM pg_stat_activity GROUP BY backend_typedecomposition query (also the falsifiable check for the next soak), and the working-set double-counting reminder.Testing
Darling suite 2170/0 (Release, full); viewer builds clean. Doc + one connection-string property — no behavioral surface beyond the pool bound.
🤖 Generated with Claude Code