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
