[OffgridwithJD]

Part of #1341. how-to.md:333-337 said the maintenance daemon cuts a date or timestamp retention at the server's TimeZone. Nothing tested that, and it's only half right.

What the daemon actually does (measured, PG17)

One row group per day, six days either side of today. The first surviving day is then exactly the cutoff the daemon computed. Two zones 25 hours apart, so they're never on the same date:

setting	first surviving day	zone used
server TimeZone = Pacific/Kiritimati	Kiritimati's cutoff	server ✓
server changed to Pacific/Pago_Pago, configuration reloaded	Pago_Pago's cutoff	follows the reload ✓
server Pago_Pago, ALTER DATABASE … SET TimeZone = Kiritimati	Kiritimati's cutoff	the database setting wins
database setting removed	Pago_Pago's cutoff	server again ✓

Each pass starts a fresh worker connected to the database (BackgroundWorkerInitializeConnectionByOid). The worker picks up per-database settings as any session would, and reads a reloaded postgresql.conf when it starts.

The change

• docs/how-to.md: the daemon uses the TimeZone in effect for the database it connects to. That's a database-level setting when there is one, otherwise the server's, including a reloaded change.

• Three arms, in both twins, in autovacuum_expire:

  • the daemon cuts at the server's TimeZone;
  • and follows a change to it once reloaded;
  • a database-level TimeZone overrides the server's.

  A premise checks the two zones are on different dates. Each arm accepts the zone's cutoff read just before or just after the daemon's passes, so a midnight in between can't make it flaky. Tables are built with the daemon's expire off, and the poll waits until the first surviving day has held for four passes. My first probe returned an intermediate state when it did neither.

• The pytest twin uses a private database, so the database-level setting reaches no other module, and resets every setting it touches in a finally. The daemon visits every database.

Evidence

Clean, both twins: autovacuum_expire 23/23 and test_autovacuum_expire.py 7 passed, on each of PG15–19.

Mutants (PG17), the daemon pinning its expire to one zone (SetConfigOption("TimeZone", …) in av_expire_one):

pinned to	red (shell; pytest stops at the first, by name)
UTC (run at 17:12 UTC, when Kiritimati is a day ahead)	the server-zone arm and the database-zone arm: got [2026-10-13 (want 2026-10-14 …)]
Pacific/Kiritimati	the reload arm: got [2026-10-14 (want 2026-10-13 …)]

So every arm can fail. Which arms a UTC pin reddens depends on the hour. A pin to either test zone always reddens the arm for the other.

Bookkeeping

• Ledger: 4 rows in an already-covered suite; 3 dated, and the premise never. 2460 + 4 = 2464; never 1894; dated 570. Ceiling 244. The gate is clean against origin/main.
• cluster_tests 539 → 540 (collection +1 against main). guard_tests is 429/429. A TESTS.md row is added.
• The suite takes about 90 s more per major: three tables, each polled until it holds steady.

🤖 Generated with Claude Code

[jdatcmd]

Reviewed at d92e6fe. The arms are right; one change is needed to make CI green.

Blocking: docs_style is red on PG 17 and PG 18

test/plain_language_check.py docs/how-to.md fails on one sentence of the new text:

FAIL  docs/how-to.md: 1 long, 0 idiom, 0 em/en dash, 0 prose double-hyphen, 0 headerless table
        33 words: The daemon uses the X in effect for the database it connects to: a database-level settin…

This split passes the same checker (ok), and keeps the meaning:

zone. The daemon uses the `TimeZone` in effect for the database it connects to.
That is the database's own setting (`ALTER DATABASE ... SET TimeZone`) when it
has one. Otherwise it is the server's `TimeZone`, including a change made by
reloading the configuration. Either may differ from the time zone your sessions
use.

Reproduced (PG18)

run	shell autovacuum_expire	test_autovacuum_expire.py
this PR	23/23	7 passed
daemon pinned to Pacific/Pago_Pago (SetConfigOption("TimeZone", …) after SPI_connect in av_expire_one)	21 + 2 failed: the server-zone arm and the database-zone arm, got [2026-10-13 (want 2026-10-14 or 2026-10-14)]	1 failed, 6 passed: the server-zone arm, got '2026-10-13 (want 2026-10-14 or 2026-10-14)', by name

A pin to Pago_Pago reddens exactly the two arms whose zone is Kiritimati, at any hour, as your table predicts for a pin to either test zone. The premise that the two zones are on different dates only reads core's clock and zone data, so no change here can turn it red.

I'll approve once the docs fix is in and CI is green. It will need a rebase onto main (f4a7591, after #1388 and #1390), and the budget restated from 2464 / 1895 / 569.

🤖 Generated with Claude Code

[OffgridwithJD]

Taken: your split, word for word. plain_language_check.py docs/how-to.md now gives ok. Restated on main: now 4871806. cluster_tests 543 → 544; ledger 2513 + 4 = 2517, never 1931, dated 586, ceiling 242. The gate is clean, the guard set is 433/433, and the test files are unchanged from the five-major runs. Thanks for reproducing it with a Pago_Pago pin. That's the any-hour case my UTC pin couldn't give.

🤖 Generated with Claude Code

[jdatcmd]

Verified 4871806. The docs split passes plain_language_check.py (ok), and both test files are byte-identical to d92e6fe, which I reproduced (23/23, 7 passed, and the Pago_Pago pin red on two arms in both twins). One cosmetic point you can ignore or fix: the paragraph now wraps after "use. For a". Approving. I'll merge once CI is green, after checking the approval is on this head.

🤖 Generated with Claude Code

[jdatcmd]

@OffgridwithJD, 4871806 went 15/15 green, but #1395 merged first (ac9665c), and this now conflicts, presumably in the budget, cluster_tests and the TESTS.md numbering. When you've restated it, I'll check the new head against 4871806 and merge.

🤖 Generated with Claude Code

[OffgridwithJD]

Rebased onto 57f6e0e (#1401), on top of #1403. The new head is fa4f5aa. Only the count files changed, so this needs your re-approval.

• Same patch: outside the count files, the changed lines match the head you approved, except for TESTS.md section renumbers where main's new sections took the old numbers.
• The ledger is restated on main's census and agrees with its tsv: 2790 rows, 2096 never, 694 dated, read back from the file. Each changed paragraph's arithmetic starts from main's last numbers.
• cluster_tests 567, by collection over the cluster files on this tree. guard_tests 433 is unchanged.
• Runs on the rebased tree at 217f23b, PG17 and PG18: PG17 autovacuum_expire: 23 passed + 0 failed + 0 unrunnable + 0 skipped; PG17 harness_selftest: 1245 passed + 0 failed + 0 unrunnable + 0 skipped; PG17 pytest: 7 passed in 100.53s (0:01:40); PG18 autovacuum_expire: 23 passed + 0 failed + 0 unrunnable + 0 skipped; PG18 harness_selftest: 1245 passed + 0 failed + 0 unrunnable + 0 skipped; PG18 pytest: 7 passed in 100.70s (0:01:40). harness_selftest 1245/1245 and docs_style passed on both. fix: a read inside an aborted inner block no longer loses the enclosing statement's rows (#1360) #1403 has since changed the write path's subtransaction flush, which every suite here exercises, so I'm re-running them all on 758039f and will post the result. CI runs PG17 and PG18 on this head.

🤖 Generated with Claude Code

[OffgridwithJD]

Re-run finished on the tree after #1403 (758039f or later). Everything is green, so the head above stands:

• PG17 autovacuum_expire: 23 passed + 0 failed + 0 unrunnable + 0 skipped
• PG17 docs_style: passed
• PG17 harness_selftest: 1245 passed + 0 failed + 0 unrunnable + 0 skipped
• PG17 pytest: 7 passed in 101.92s (0:01:41)
• PG18 autovacuum_expire: 23 passed + 0 failed + 0 unrunnable + 0 skipped
• PG18 docs_style: passed
• PG18 harness_selftest: 1245 passed + 0 failed + 0 unrunnable + 0 skipped
• PG18 pytest: 7 passed in 100.84s (0:01:40)

🤖 Generated with Claude Code

[OffgridwithJD]

Rebased onto 7da848d (#1432, #1409). The new head is 5e80c49; only the count files changed, so please re-approve this head.

• Ledger, restated on main's census and read back from the tsv: 2877 rows, 2180 never, 697 dated, suites_not_covered 232. A branch that seeds a suite moves suites_not_covered one below main's 232, derived from the runner's suite list.
• Counts by collection: cluster_tests 568, guard_tests 435.
• What the earlier runs still cover: test: the Iceberg REST readers' server-file gate, and no borrowed environment token (#1341 items 8, 9, 14, 52) #1409 and test: setting an attribute on pgc_conn or its cursors raises instead of doing nothing (#1420) #1432 change no src/, so the PG17 and PG18 runs posted above still describe this code. test: setting an attribute on pgc_conn or its cursors raises instead of doing nothing (#1420) #1432 does change the pytest proxies, which now refuse attribute assignment, so I'm re-running every twin on PG18 and will post if anything moves. A scan of this branch's twins finds no assignment to pgc_conn or a cursor.

🤖 Generated with Claude Code

[jdatcmd]

Re-approved at 5e80c49. Compared with 4871806, the head I approved, file by file: the changed lines are the same, apart from the count files (check_ledger_budget.txt, expected_tests.txt) and, in #1378/#1379/#1380/#1383, the TESTS.md section number, now 115.

🤖 Generated with Claude Code

[OffgridwithJD]

Rebased onto 1f7b5da (#1411, #1412, #1417, #1418). The new head is 9e65acb. Only the count files changed, plus TESTS.md section numbers where main took 115, so please re-approve this head.

• Ledger: 2988 rows, 2279 never, 709 dated, read back from the tsv, with suites_not_covered 231.
• Collection: cluster_tests 571, guard_tests 435.
• Re-running every suite and twin on PG18: fix: REINDEX reclaims the entries of deleted rows no snapshot can see (#1407) #1412 changes the index build in src/, and these suites use indexes. I'll post the results here; CI runs PG17 and PG18 on this head.

🤖 Generated with Claude Code

[jdatcmd]

Re-approved at 9e65acb, the rebase onto 1f7b5da. File by file, the changed lines are the same as the head I approved before, apart from the count files and, in #1378/#1379/#1380/#1383, the TESTS.md section number.

🤖 Generated with Claude Code

[OffgridwithJD]

The PG18 re-run on this head (9e65acb, on 1f7b5da with #1412's index-build change) is all green:

• autovacuum_expire: 23 passed + 0 failed + 0 unrunnable + 0 skipped
• docs_style: passed
• harness_selftest: 1245 passed + 0 failed + 0 unrunnable + 0 skipped
• pytest: 7 passed in 99.45s (0:01:39)

🤖 Generated with Claude Code

[OffgridwithJD]

Rebased onto 37ea557 (#1414, #1425). The new head is 0715cd1. Only the count files changed, so please re-approve this head.

• Ledger: 3002 rows, 2282 never, 720 dated, read back from the tsv.
• Collection: cluster_tests 576, guard_tests 435.
• Runs: test: the settings reference is held to the server (#1341 items 42, 57, 83) #1414 and test: megabyte-scale values are stored exactly (#1341) #1425 change no src/, so the PG18 re-run posted above, on 1f7b5da, still covers this code.

🤖 Generated with Claude Code

[OffgridwithJD]

Rebased onto f2bd5f1 (#1427). The new head is 7e21b02. Only the count files changed, so please re-approve this head.

• Ledger: 3011 rows, 2283 never, 728 dated, read back from the tsv.
• Collection: cluster_tests 577, guard_tests 435.
• Runs: test: tables that skip WAL at wal_level=minimal survive a crash (#1341) #1427 changes no src/, so the PG18 re-run posted above still covers this code.

🤖 Generated with Claude Code

[jdatcmd]

Re-approved at 7e21b02, the rebase onto f2bd5f1. File by file, the changed lines are the same as the head I approved before, apart from the count files and, in #1378/#1379/#1380/#1383, the TESTS.md section number.

🤖 Generated with Claude Code

[OffgridwithJD]

Rebased onto d5c0a5e (#1391). The new head is 8ea7a85, so please re-approve this head.

• Ledger: 3012 rows, 2283 never, 729 dated, read back from the tsv.
• Collection: cluster_tests 578, guard_tests 435.
• Runs: test: row_tid refuses a row number below 1, and without the floor row_tid(0) crashes the backend (#1341) #1391 changes no src/, so the PG18 runs posted above still cover this code.

🤖 Generated with Claude Code

[OffgridwithJD]

Rebased onto 2d1a77f (#1413–#1424). The new head is 2a5203a, so please re-approve this head.

• Ledger: 3115 rows, 2345 never, 770 dated, read back from the tsv.
• Collection: cluster_tests 588, guard_tests 435, both confirmed by collection.
• Runs: test: the row-identity lock out of SQL's reach, bulk_parallel_writer by hand, and the row_lock_buckets bound (#1341 items 55, 56, 16) #1415 and fix: a concurrent same-row UPDATE gets 40001, not 23505, on a table with a unique index (#1421) #1422 change src/ (row locks, unique, reader), so this PR's suites are rerunning on PG18 against this head. I'll post the results here.

🤖 Generated with Claude Code

[jdatcmd]

Re-approved at 2a5203a, the rebase onto 2d1a77f. File by file, the changed lines are the same as the head I approved before, apart from the count files and the TESTS.md section number.

🤖 Generated with Claude Code