Hi, On 2018-10-12 09:56:14 +0900, Michael Paquier wrote: > On Fri, Oct 12, 2018 at 12:17:57AM +0000, Michael Paquier wrote: > > Add TAP tests for pg_verify_checksums > > > > All options available in the utility get coverage: > > - Tests with disabled page checksums. > > - Tests with enabled test checksums. > > - Emulation of corruption and broken checksums with a full scan and > > single relfilenode scan. > > culicidae is failing after this commit in an interesting way, so we > really needed some tests for this utility: > https://buildfarm.postgresql.org/cgi-bin/show_history.pl?nm=culicidae&br=HEAD > > ok 7 - fails with corrupted data status (got 1 vs expected 1) > not ok 8 - fails with corrupted data stdout /(?^:Bad checksums:.*1)/ > > # Failed test 'fails with corrupted data stdout /(?^:Bad checksums:.*1)/' > # at t/002_actions.pl line 57. > # '' > # doesn't match '(?^:Bad checksums:.*1)' > not ok 9 - fails with corrupted data stderr /(?^:checksum verification > failed)/ > > So the checksum failure is happening, but the output is not present. > What's not clear to me is that all the other hosts running Debian SID > don't complain, and that the follow-up test on a single relfilenode is > able to pass with a test much similar to the previous one.
culicidae tests EXEC_BACKEND, so there's an explanation as to why it sometimes behaves differently. But here I don't immediately see how that'd matter. Probably still worth verifying that it's not somehow caused by that. > Is the issue > that we should just call fflush() on stderr and stdout at the end of > main() in pg_verify_checksum.c? Shouldn't we back-patch that? I don't see how that'd would change anything. A "missing" fflush() isn't a licence to simply throw away buffer contents, so I doubt it's just that. Greetings, Andres Freund
