Release 3.10.0: last changelog splice and README sync

CHANGELOG.md

@@ -21,13 +21,14 @@ Releases before 3.0.0 are not archived: those entries carry no prose to move.
 
 ## [Unreleased]
 
-## [3.10.0] - 2026-10-08
+## [3.10.0] - 2026-10-09
 
 Full entries: [docs/changelog/3.10.md](docs/changelog/3.10.md)
 
 ### Important
 
-- **Upgrading from 3.9 runs the Darling store migrations V158 through V170 on the service's first start**
+- **Upgrading from 3.9 runs the Darling store migrations V158 through V173 on the service's first start**
+- **On Windows, upgrading an install that ordinary users can write to stops once and prints steps to move it** ([#5627])
 
 ### Added
 
@@ -327,6 +328,8 @@ Full entries: [docs/changelog/3.10.md](docs/changelog/3.10.md)
 - **"Collection Falling Behind" no longer fires in the first hour after every start** ([#5599])
 - **A hung test shard names its test and keeps its logs** ([#5591])
 - **One-day Custom Views panels on Query Store data read an hourly rollup, or are refused up front** ([#5588], [#5610])
+- **Darling's hourly maintenance step over stored analysis findings no longer times out on a large store** ([#5626])
+- **Upgrade refusals no longer list the service's own files** ([#5628])
 - **Darling's deadlock maintenance logs a line when a stage recovers after a failed pass** ([#5637])
 
 ## [3.9.0] - 2026-10-02
@@ -5189,5 +5192,8 @@ Full entries: [docs/changelog/3.0.md](docs/changelog/3.0.md)
 [#5598]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5598
 [#5599]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5599
 [#5610]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5610
+[#5626]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5626
+[#5627]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5627
 [#5636]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5636
 [#5637]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5637
+[#5628]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5628

README.md

@@ -268,6 +268,7 @@ All data is stored in `%LOCALAPPDATA%\PerformanceMonitorLite-Data\` — a differ
 - **Hot data** in DuckDB 1.5.2 — non-blocking checkpoints, free block reuse, stable file size without periodic resets
 - **Archive** to Parquet with ZSTD compression (~10x reduction) — automatic monthly compaction keeps file count low (~75 files vs thousands)
 - **Retention**: 3-month calendar-month rolling window
+- **Memory limit**: DuckDB's memory limit is a setting (Settings, Dashboard Defaults, "DuckDB memory limit"). The default is 2 GB, and it can go from 1 GB up to 80% of memory. A change applies after a restart.
 - Typical size: ~50–200 MB per server per week
 
 ### Lite Configuration
@@ -356,7 +357,11 @@ The **Lite** app and the **Darling** viewer share the same tab layout (the viewe
 | **Job History** | SQL Agent job runs retained from `msdb` |
 | **Availability Groups** | Replica and per-database health from the Availability Group collectors |
 
-Both feature auto-refresh, configurable time ranges, chart drill-down to Active Queries, right-click CSV export, system tray integration, dark and light themes with user-adjustable palette colors (see [Themes and colors](Lite/README.md#themes-and-colors)), and timezone display options (server time, local time, or UTC). The Darling viewer adds a fleet sidebar and per-server tabs, and it shows a PostgreSQL target on its own set of tabs. See [Darling/README.md](Darling/README.md). The deprecated Dashboard's six-tab-group layout is documented in [deprecated/Dashboard/README.md](deprecated/Dashboard/README.md).
+Both feature auto-refresh, chart drill-down to Active Queries, right-click CSV export, system tray integration, dark and light themes with user-adjustable palette colors (see [Themes and colors](Lite/README.md#themes-and-colors)), and timezone display options (server time, local time, or UTC).
+
+Both also share one time range picker with the web pages. It has presets, calendar periods, and typed ranges such as `last 3 days` or `since 9am`. A text column's filter lists its values to tick, like Excel, and stays set across refreshes and restarts.
+
+The Darling viewer adds a fleet sidebar and per-server tabs, and it shows a PostgreSQL target on its own set of tabs. See [Darling/README.md](Darling/README.md). The deprecated Dashboard's six-tab-group layout is documented in [deprecated/Dashboard/README.md](deprecated/Dashboard/README.md).
 
 The Darling web dashboard has these pages in its sidebar:
 

docs/changelog/3.10.md

@@ -3,11 +3,12 @@
 The full changelog entries for 3.10.0. [CHANGELOG.md](../../CHANGELOG.md) carries the
 compacted index for every version, this one included, and is where `[Unreleased]` is written.
 
-## [3.10.0] - 2026-10-08
+## [3.10.0] - 2026-10-09
 
 ### Important
 
-- **Upgrading from 3.9 runs the Darling store migrations V158 through V170 on the service's first start** - they are almost all new tables that start empty or one-row setting columns: the install id's record of the store's cluster and database (V158, V159), a collector run time table (V160), per-day summaries for Query Store and plan regressions (V161, V168), the store's own slow-read and statement history (V162, V163), an hourly row-count ledger for query stats (V164), the password key and saved-password tables (V165, V167), a PagerDuty auto-resolve setting (V166), AWS role columns for monitored servers (V169) and an hourly PostgreSQL I/O rollup (V170). None of them rewrites a large table or needs an offline window. The two that read existing rows work on the registry of monitored servers and the notification settings, one row per server or one row in all: V167 records one row per saved old-format password, and V169 adds columns and a check constraint to `config.config_monitored_servers`. V166 adds a column with a constant default, which PostgreSQL 11 and later does without rewriting the table, and V168 adds a trigger to `collect.query_store_interval_latest`, which takes a short lock and rewrites nothing. No maintenance window is needed.
+- **Upgrading from 3.9 runs the Darling store migrations V158 through V173 on the service's first start** - they are almost all new tables that start empty or one-row setting columns: the install id's record of the store's cluster and database (V158, V159), a collector run time table (V160), per-day summaries for Query Store and plan regressions (V161, V168), the store's own slow-read and statement history (V162, V163), an hourly row-count ledger for query stats (V164), the password key and saved-password tables (V165, V167), a PagerDuty auto-resolve setting (V166), AWS role columns for monitored servers (V169) an hourly PostgreSQL I/O rollup (V170), the two Query Store interval tables turned into day-partitioned tables (V171, V172) and an empty rollup of Query Store intervals with its triggers (V173). None of them rewrites a large table or needs an offline window. The two that read existing rows work on the registry of monitored servers and the notification settings, one row per server or one row in all: V167 records one row per saved old-format password, and V169 adds columns and a check constraint to `config.config_monitored_servers`. V166 adds a column with a constant default, which PostgreSQL 11 and later does without rewriting the table, and V168 adds a trigger to `collect.query_store_interval_latest`, which takes a short lock and rewrites nothing. V171 and V172 attach each current Query Store interval table as a legacy partition without copying or scanning it (1.1 s and 20 ms on a large store), and V173 creates its rollup tables empty and clones two triggers onto the existing partitions without scanning them. No maintenance window is needed.
+- **On Windows, upgrading an install that ordinary users can write to stops once and prints steps to move it** ([#5627]) - Before it locks the install folder, 3.10 checks who can write to it. When ordinary users can write to the folder of an existing install, `upgrade-darling.ps1` and `install-darling.ps1` stop and print numbered steps. The common case is a folder made directly under `C:\`, which takes its write permission from the drive. An install whose folder an admin fixed by hand with the commands 3.9.0 printed after a failed lock stops too. The steps stop the service and extract the new zip into a new, empty folder under `C:\Program Files`. They copy `darling.json` and run `install-darling.ps1` from the new folder, which points the existing service at it. The logon account, the saved credentials and the store are kept. Then start the service, check that it collects, and delete the old folder. The new folder passes the check, so this happens once.
 
 ### Added
 
@@ -327,6 +328,8 @@ compacted index for every version, this one included, and is where `[Unreleased]
 - **"Collection Falling Behind" no longer fires in the first hour after every start** ([#5599]) - It fired minutes after a start. The alert now leaves out what was counted in the first 15 minutes after the service starts. A store that stays behind fires about 30 minutes after the start. A stall, a clock step, a pause ending or the launch guard's release does not give those minutes again. The alert text names the minutes it judged, and in the first hour the log line says "last N minutes, since the service started". Slots due while a server's connect run was still seeding its schedule are no longer counted as skipped.
 - **A hung test shard names its test and keeps its logs** ([#5591]) - A shard that ran into the job timeout lost its log and its timing. The Darling and Lite test steps now have their own timeout under the job's, so the upload steps still run. The runner reports any test that has run for 5 minutes, and its output is uploaded. The nightly runs get the same report. One test waited up to an hour while holding a lock. It now gives up after 60 seconds.
 - **One-day Custom Views panels on Query Store data read an hourly rollup, or are refused up front** ([#5588], [#5610]) - On a large store, a one-day panel read 8.46 M rows and took 55.2 s against the 60 s limit. Darling now keeps an hourly rollup of the Query Store wide table and reads closed hours from it. The answer is exactly what the wide table returns. A panel over the row limit is refused up front with the reason. A ranked panel reads its rows once only when that cannot fill the temp file limit. A rollup build waits only for an open write to the wide table that began before its hour was safe to build. A long wait is logged as a warning that names the session. A schema upgrade that cannot get its table lock in time logs every session that holds a lock on the store's tables.
+- **Darling's hourly maintenance step over stored analysis findings no longer times out on a large store** ([#5626]) - The step that re-masks stored analysis findings paged the table with a sort over a full scan. On a store with 600,000 findings each page read about 1 GB and timed out. It now reads a fixed 16 MiB slice of the table per page, so a page costs the same however large the table is or however many findings match. On a test store a page read 2,048 buffers instead of 35,698 and took 22 to 43 ms instead of 202 ms. The two stages over stored alerts now read one server at a time through the alert log's existing index, and their pages are bounded too. No store migration.
+- **Upgrade refusals no longer list the service's own files** ([#5628]) - The pre-lock check listed about 1,740 files the service had extracted. It now trusts the service's account only in the folders and files the service writes. A refused existing install gets numbered steps to move to a new folder, with the service, darling.json and store kept. upgrade-darling.ps1 now runs on Windows PowerShell 5.1 from its staging folder. A new CI check runs both scripts over real 3.7.1 and 3.9.0 installs. The compose quickstart pulls the latest image.
 - **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.
 
 [#4902]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/4902
@@ -623,5 +626,8 @@ compacted index for every version, this one included, and is where `[Unreleased]
 [#5598]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5598
 [#5599]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5599
 [#5610]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5610
+[#5626]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5626
+[#5627]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5627
+[#5628]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5628
 [#5636]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5636
 [#5637]: https://github.com/erikdarlingdata/PerformanceMonitor/pull/5637

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   292  06c70930fcfc200f8c4268f774f96127d35f330322145018a6d6ed830361f7d7
+3.10.0   295  ef28f41a6dd880e58385f22457d758b44db9b24991ebf3f832629e7792ddaa30
 3.9.0   760  3b0001be584135029dc4dc921cae4c9f15ca09ace77230625ec0974a22d7ede8
 3.8.0    35  7c531d7f349f1432913ae72b9ea8542821878e15f1aafe9c8a773abc55e7a5e1
 3.7.0   279  8912147a684e50dbd37b772b44688d68b71f46b854b5f90a2cfd9aeca5c71021