Re: Do we want to avoid checksumming extra files in the datadir? [was: BUG #19647]

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