Hi Jacob, > Are there are any corner cases I've missed where you want pg_checksums > to check a temporary relation's relfiles?
Skipping them looks right to me. A normal server restart removes leftover temporary files, and after a backend crash they are also removed by default. I set remove_temp_files_after_crash = off to retain them, created temporary tables in pg_default and a separate tablespace, then sent SIGKILL (kill -9) to the backend that created both tables. After automatic recovery, I cleanly shut down the server. Both temporary relation files were still present. With v2, pg_checksums --check --verbose skipped both files. The next postmaster startup removed them even with remove_temp_files_after_crash still off. The --filenode changes look fine too. Zero is not a valid filenode, so rejecting it is reasonable. Numeric comparison also makes sense: adding leading zeroes to the argument does not identify a different relation. In my test, --filenode 0016385 checked the same three files as --filenode 16385. After I deliberately corrupted a page checksum in that relation, --filenode 0016385 reported the checksum failure. --filenode 0 was rejected. Could we add a leading-zero --filenode case to check_relation_corruption() in src/bin/pg_checksums/t/002_actions.pl? After corrupt_page_checksum(), using "00$relfilenode_corrupted" should still report one bad checksum and exit 1. Checking only for success would also pass with the old behavior of matching no files. Could 0003's commit message also mention the change from string to numeric comparison for --filenode, including the leading-zero behavior? The core regression, pg_checksums and pg_basebackup tests passed, as did t/014_unlogged_reinit.pl and t/022_crash_temp_files.pl in src/test/recovery. I didn't find a functional issue with v2. Regards, Rui
