[OffgridwithJD]

Part of #1341: the medium error-path item "a date32 or date64 value outside PostgreSQL's date range is refused with 22008". Its time and timestamp siblings were tested; the date check had no arm.

The arms

Three new fixtures in arrow_import.sh's pyarrow block, each valid in its own carrier:

• a date32 at 2^31−1 days, past 5874897 AD;
• a date32 at −2^31 days, before 4713 BC;
• a date64 at 2^62 ms.

Each is imported into a date column and must answer 22008.

PG17, main 1933577 against this branch, with the date decode's IS_VALID_DATE check removed:

	main	this branch
arrow_import.sh	72/72	all three red, "got [00000] want [22008]": each import succeeded with a date nothing reads back as the file's

Shell only. arrow_import has no pytest twin; its missing twin is its own #1341 twin-parity item. These arms will be in it when it is written.

Evidence

• Clean: arrow_import 75/75 on each of PG 15–19.
• Ledger: arrow_import had no ledger rows, so it is seeded with all 75 checks. 2343 → 2418 rows, the census 1796 → 1868, and suites_not_covered 246 → 245. The three new arms are dated.
• Overlap: test: parallel_copy and parallel_export_parquet refuse a table the caller holds no grant on; import_export_privilege gets its twin and its ledger (#1341) #1362 also seeds a suite, so whichever lands second takes the ceiling to 244.
• Gate: rc=0, and the ceiling falls.
• Database-free set: 429 passed.

🤖 Generated with Claude Code

[jdatcmd]

Approving the content at e293e62. On PG17 I reproduced the claim with IS_VALID_DATE removed from the date decode:

• main: arrow_import passes 72/72.
• this head: all three new arms fail with "got [00000] want [22008]".

Before merge: rebase and restate; it seeds arrow_import, so the ceiling falls by one.

[OffgridwithJD]

Rebased onto 9b3c181 (#1362 merged): now e725166. Only the budget conflicted. Restated on main's figures: ledger rows 2385 + 75 = 2460, never 1821 + 72 = 1893, dated 564 + 3 = 567. suites_not_covered is 244: git auto-resolved it to 245 because both sides made the same 246 → 245 edit, and I corrected it by hand. arrow_import.sh is byte-identical to the version the 75/75 five-major runs used. The gate is clean against origin/main (census 1893 = ledger, ceiling 245 → 244). I'll report back when CI is green.

🤖 Generated with Claude Code

[jdatcmd]

Re-approving the rebased head e725166. Checked against e293e62:

• Patch: identical outside the three count files.
• Ledger: 2460 rows / 1893 never (main 2385/1821). No duplicate keys, no dated premise rows, none of main's rows dropped or changed.
• Ceiling: 244. Thanks for catching git's auto-resolution to 245.
• CI: 15/15.

Merging.

[jdatcmd]

@OffgridwithJD, merged as d7cd8f3. Main now: 2460 rows / 1893 never, suites_not_covered 244. #1365 is next.

Reviews from this round, all reproduced on PG18. Details are on each PR.

• Approved:
  • test: set_options refuses an unknown compression name and keeps the stored one; encode_effort seeds the ledger (#1341) #1371, test: analyze() refuses a named column the table does not have, before writing any statistics; analyze_function seeds the ledger (#1341) #1373, test: objstore_userinfo gets its pytest twin, every check by the shell's name (#1341) #1378 and test: objstore_crlf gets its pytest twin, every check by the shell's name; seeds the ledger (#1341) #1380, each needing a rebase;
  • test: a projection sorted on a type with no ordering is refused (0A000), not a backend crash; projections seeds the ledger (#1341) #1375, where the signal-11 crash is confirmed.
• Changes requested:
  • Four for a premise: that a product mutation reddens: test: half a retention declaration is no retention, in both twins (#1341) #1370 (set_options), test: a rollup's min and max keep each source column's collation across a refresh, in both twins (#1341) #1372 (refresh's return value), test: compact_rewrite's max_groups caps one call and the call returns what it rewrote; native_reclaim seeds the ledger (#1341) #1374 (stripe_row_limit) and test: objstore_allowlist gets its pytest twin, and its admin-override arm can now fail; seeds the ledger (#1341) #1379 (the GUC default). Each fix is a rename and a dated row.
  • test: pytest twins for vacuum_lock_privilege, vm_privilege and debug_hook_privilege; vm's owner controls get their own table; seeds the ledger (#1341) #1381: the "no lock request queued" check runs after the probes have ended, so it can't fail. Also an owner control named as a premise.
• Filed pgcolumnar.truncate() takes its lock and names the relation type before checking ownership (the #749 pattern) #1384 from the test: pytest twins for vacuum_lock_privilege, vm_privilege and debug_hook_privilege; vm's owner controls get their own table; seeds the ledger (#1341) #1381 review: pgcolumnar.truncate() locks and names the relation type before its owner check.
• Rollups: the source can be dropped from under a rollup (refresh then fails on a dead OID), and DROP VIEW of a rollup orphans its catalog row and partials #1376 and Rollups do not survive pg_dump/pg_restore: the view and partials come back, the rollup catalog does not, and refresh says 'not a rollup' #1377: my design notes are on both. For Rollups do not survive pg_dump/pg_restore: the view and partials come back, the rollup catalog does not, and refresh says 'not a rollup' #1377: storageid_seq isn't dumped, so a restored source can reuse the storage id that a dumped rollup row names. I suggest registering the sequence.
• Planning-buffer counts wobbled in CI and the cause was never found: audit the other arms that count buffers #1298: plan posted. Counting in the measured statement's own transaction instead of pg_statio. Both twins of both suites are green, with red-first arms. The PR follows when the five-major runs finish.

[OffgridwithJD]

@jdatcmd CI is green at e725166 (15/15). The only change since your approval is the rebase onto 9b3c181, and the restated budget is described above. Ready to merge in queue order; #1365 is next.

🤖 Generated with Claude Code