Release 3.10.0: changelog entries for the last fixes

CHANGELOG.md

@@ -137,6 +137,7 @@ Full entries: [docs/changelog/3.10.md](docs/changelog/3.10.md)
 - **Each PostgreSQL server in Darling can use its own AWS role** ([#5468])
 - **Filter web grid columns by number, text operator or empty cell** ([#5255])
 - **Web sidebar search and tag grouping** ([#5259])
+- **Lite has a DuckDB memory limit setting** ([#5553])
 
 ### Changed
 
@@ -293,6 +294,13 @@ Full entries: [docs/changelog/3.10.md](docs/changelog/3.10.md)
 - **A managed store near a WAL size step no longer rewrites its settings file on every restart** ([#5544])
 - **The start-up check for gaps in the rollups no longer reads a whole chunk of a daily rollup to look for one missing day** ([#5538])
 - **The fleet overview tool and the web Fleet page total PostgreSQL deadlocks faster over multi-day windows** ([#5536])
+- **The module map no longer re-reads two days of procedure stats at every restart** ([#5528])
+- **Custom Views, custom alert rules and alert notebook charts read far fewer rows for a scoped server** ([#5537])
+- **Query Store reads that use the stored interval tables no longer miss an interval that started up to about a day before the table's oldest data** ([#5543])
+- **A quiet server's job history and default trace watermark read touches a week of data, not its whole history** ([#5532])
+- **Small fixes across Lite and the Darling Viewer from the final release walk: Collector Schedules wording, Server Inventory health, time columns, screen-reader names and FinOps dashes** ([#5542])
+- **Lite's Job History tab reads only the selected time range, and tab loads no longer wait on the database from the window** ([#5553])
+- **Darling stops a rollup's refresh jobs before it drops the rollup** ([#5552])
 
 ## [3.9.0] - 2026-10-02
 
@@ -5120,10 +5128,17 @@ Full entries: [docs/changelog/3.0.md](docs/changelog/3.0.md)
 [#5511]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5511
 [#5524]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5524
 [#5527]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5527
+[#5528]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5528
 [#5529]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5529
 [#5530]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5530
+[#5532]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5532
 [#5533]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5533
 [#5534]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5534
 [#5536]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5536
+[#5537]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5537
 [#5538]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5538
+[#5542]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5542
+[#5543]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5543
 [#5544]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5544
+[#5552]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5552
+[#5553]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5553

docs/changelog/3.10.md

@@ -121,6 +121,7 @@ compacted index for every version, this one included, and is where `[Unreleased]
 - **Each PostgreSQL server in Darling can use its own AWS role** ([#5468]) - a PostgreSQL server on Amazon RDS or Aurora can now name the AWS role Darling assumes for it. A server's darling.json entry takes `awsRoleArn` and an optional `awsExternalId`. The web Servers page, the MCP `add_servers` and `edit_server` tools and `--add-server` take `aws_role_arn` and an optional `aws_external_id`, and the desktop viewer's Add and Edit server dialog has matching fields. Darling assumes that role for the server's AWS calls (the host check, CPU and host memory from Performance Insights, and the log reads behind plan capture, deadlocks and log events), so a cluster in another AWS account needs no process-wide AWS profile. A server with no role uses the process's own credentials as before. The web, MCP, desktop viewer and `--add-server` can set only roles listed in the new `allowedAwsRoles` setting in darling.json (an exact ARN, or a whole account id: a bare 12-digit id is an account in the aws partition, and aws-cn:123456789012 or aws-us-gov:123456789012 names the others), plus the roles darling.json's own servers name. A role that is not allowed, is in the wrong partition or is refused by AWS shows on that server's collection health as PERMISSIONS with a message naming the role and whether an external ID is set. A host with no AWS credentials, or an STS fault, shows as ERROR with a fixed sentence plus the SDK exception type and AWS error code. The external ID is never returned or written to a log. A store schema step adds the role and external ID columns to the server registry.
 - **Filter web grid columns by number, text operator or empty cell** ([#5255]) - a column filter can now match greater/less than, equals, not equals, starts with, ends with, is empty and is not empty, comparing the real numbers rather than the formatted text; plain typing still does a contains match.
 - **Web sidebar search and tag grouping** ([#5259]) - the web sidebar's server list has a search box (name, server name or tag) and a Group by tag toggle with Favourites first, the tag tree, then Untagged. The search term lasts across refreshes; the toggle and collapsed groups are remembered per browser.
+- **Lite has a DuckDB memory limit setting** ([#5553]) - Settings, Dashboard Defaults, "DuckDB memory limit" sets the main DuckDB connection's memory limit (default 2 GB, range 1 GB to 80% of memory, applied after a restart). The thread count follows it as the smaller of 8, the core count and the limit divided by 256 MB, and out-of-memory errors name the setting and its current value, and so does the log.
 
 ### Changed
 
@@ -293,6 +294,13 @@ compacted index for every version, this one included, and is where `[Unreleased]
 - **A managed store near a WAL size step no longer rewrites its settings file on every restart** ([#5544]) - The managed settings file derives max_wal_size and min_wal_size from the data volume's free space. A volume within a few hundred MB of a 16, 32, 64 or 128 GB step got another size on the next service start. The file was rewritten with nothing else changed. The file now keeps its size while it is within one eighth of the current free space, the same tolerance the settings check uses. Halved or doubled headroom still moves it. A hand-edited file is still left alone.
 - **The start-up check for gaps in the rollups no longer reads a whole chunk of a daily rollup to look for one missing day** ([#5538]). The check looks for days or hours where a rollup has no data but the raw table does. For a day the rollup lacked, it read a whole uncompressed chunk to find that out. On a large store that was about 14 GB and 50 seconds per run. It now looks a missing day up in the index instead of reading the whole chunk, and finds the same gaps. On the large store the lookup measured 0.89 ms and 3 buffers against 11.2 s and 240,137 buffers.
 - **The fleet overview tool and the web Fleet page total PostgreSQL deadlocks faster over multi-day windows** ([#5536]). These totals sorted and differenced every server's samples. Both surfaces accept windows up to 7 days, and on a store with 50 PostgreSQL targets a 7-day total took about 6.8 seconds. They now set aside the databases whose deadlock counter had the same value in every sample in the window and difference only the rest. On that store a 7-day total now takes about 0.7 seconds. The totals are unchanged, including after a counter or statistics reset and for databases with missing counter values.
+- **The module map no longer re-reads two days of procedure stats at every restart** ([#5528]). Service start and the daily sweep each re-read two days of procedure stats (about 100 s of store time per call on a large store) although the hourly refresh already keeps the map current. Both now read 30 hours behind the map's watermark, which still repairs rows that were saved late; the full two-day read stays for an empty map or one with no watermark.
+- **Custom Views, custom alert rules and alert notebook charts read far fewer rows for a scoped server** ([#5537]). A panel, rule or chart scoped to named servers now finds those servers by identity, so the read no longer scans every row of the window and throws most of them away. A renamed server's scope also includes the rows it wrote under its earlier name, and those rows keep that earlier name, so a panel grouped by server can show a separate series for it. A scoped name that the monitored server list does not hold still matches the rows stored under it. If a new server is later added under a renamed server's earlier name, a scope on that name now covers only the new server, so the earlier server's rows under that name no longer appear in it.
+- **Query Store reads that use the stored interval tables no longer miss an interval that started up to about a day before the table's oldest data** ([#5543]). The Queries grid, the MCP top read and the plan regression read use stored interval tables when they cover the requested range. Those tables drop an interval by its first execution time, while the raw snapshots drop by collection time, so an interval that started up to about a day before the table's oldest data could be left out of those reads. This could happen on default retention, for a custom range that starts just above the table's oldest data on a database with 24-hour Query Store intervals. These reads now use a stored table only when it reaches far enough below the range to hold every interval the range can need, and otherwise read the raw snapshots.
+- **A quiet server's job history and default trace watermark read touches a week of data, not its whole history** ([#5532]). When a server had no job run or trace event for 6 hours, the watermark read scanned the server's whole stored history, about 5,400 blocks a call for job history. It now tries the last seven days first, and the CPU and per-database watermark reads do the same, so a quiet Azure database no longer reads its whole history every cycle. The value is the same, except that job history's run time can come back older, which only makes the next collection re-check a little more and never skips anything.
+- **Small fixes across Lite and the Darling Viewer from the final release walk: Collector Schedules wording, Server Inventory health, time columns, screen-reader names and FinOps dashes** ([#5542]) - Every server showed Preset "Custom" next to Status "Default", which read as a contradiction. Status now reads "Uses default" or "Own schedule", both column headers have a tooltip, and a Custom preset has a tooltip naming the collector intervals that differ from the closest preset. The Server Inventory Health column in Lite and the Darling Viewer, web page and MCP tool now shows the same score as that server's Utilization view; it used to show almost the same number for every server because it scored average CPU against fixed memory and storage values. The Darling Viewer's Overview card shows the date of a collection that is not from today, the Alert History and Job History time columns name the clock they read on (and Viewer Job History rows read on their own server's clock), Alert History says when it shows only the newest 500, the Overview search also narrows the fleet roll-up above the cards ("Monitoring 2 of 9 servers"), and an Availability Group on old data reads Stale instead of Healthy in the Viewer and Lite. Screen readers now read column headers, their filter buttons, empty cells (text or templated), grid rows and server list items by name in Lite and the Viewer (they read as "System.Windows.Controls.StackPanel", a bare glyph or a type name before; a row now reads as its first two visible columns, such as "Time 06:01:12, Server example-sql-01"). The FinOps Utilization view in Lite and the Darling Viewer shows dashes for Avg, P95 and Max CPU when a server has no CPU sample in the last 24 hours (they read 0.00%, 0.00% and 0%) and hides the database sizes chart then, and the web page's Utilization read and the MCP tool return null for those three figures. The Server Inventory dash in place of a health score now has a tooltip that names both reasons for it (no CPU sample in the last 24 hours, or no memory sample collected), and Lite's Alert History count follows a column filter, as the Darling Viewer's does.
+- **Lite's Job History tab reads only the selected time range, and tab loads no longer wait on the database from the window** ([#5553]) - Every Job History read loaded and sorted each server's whole archived job history before it dropped the runs outside the selected range. On a 30-server test store that cost 4 to 8 seconds and 600 to 730 MB per server, and on a larger store it can run out of DuckDB's memory cap. The archive view now applies the time range first: 0.5 to 0.7 seconds, under 300 MB, same rows. The Availability Groups and FinOps tab loads, opening a plan viewer from a tab, the Overview's tag refresh, and the Manage Tags, Database State Overrides, history, drill-down and Collection Log windows also awaited their database reads and writes on the window's own thread. There they can wait behind archival or a long read. They now read off that thread.
+- **Darling stops a rollup's refresh jobs before it drops the rollup** ([#5552]). When Darling retired or rebuilt a rollup (a TimescaleDB continuous aggregate), its background refresh was sometimes still running. The drop failed with "tuple concurrently deleted", and in one test run the PostgreSQL backend running the refresh crashed. Darling now stops the rollup's jobs and waits up to 30 seconds for a running refresh to end. TimescaleDB ends it within seconds, as one failed run, so a rollup that stays can raise one information-level job-failure alert. If the wait runs out or the drop fails, Darling restarts the jobs and tries again on the next pass.
 
 [#4902]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/4902
 [#4944]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/4944
@@ -554,10 +562,17 @@ compacted index for every version, this one included, and is where `[Unreleased]
 [#5511]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5511
 [#5524]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5524
 [#5527]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5527
+[#5528]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5528
 [#5529]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5529
 [#5530]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5530
+[#5532]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5532
 [#5533]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5533
 [#5534]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5534
 [#5536]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5536
+[#5537]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5537
 [#5538]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5538
+[#5542]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5542
+[#5543]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5543
 [#5544]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5544
+[#5552]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5552
+[#5553]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5553

tools/changelog/archive-census.txt

@@ -10,7 +10,7 @@
 # fails CI. It is the durable half of the proof; `roundtrip` is the whole-document half and
 # needs the pre-split revision to compare against.
 
-3.10.0   257  a4ad534519744df020059cb5b19e5888d0b50ac24176c54ed11c7722d0e5645b
+3.10.0   265  1431fd261121aecc257ab39de95dcfef5292a17482977972618690b84f49426c
 3.9.0   760  3b0001be584135029dc4dc921cae4c9f15ca09ace77230625ec0974a22d7ede8
 3.8.0    35  7c531d7f349f1432913ae72b9ea8542821878e15f1aafe9c8a773abc55e7a5e1
 3.7.0   279  8912147a684e50dbd37b772b44688d68b71f46b854b5f90a2cfd9aeca5c71021