Horton

Thread

Commits

  1. Fix some issues with TAP tests of pg_basebackup

  2. Fix some issues with TAP tests of pg_basebackup and pg_verify_checksums

  1. [Patch] checksumming-related buglets in pg_verify_checksums/pg_basebackup TAP tests

    Michael Banck <michael.banck@credativ.de> — 2019-02-14T14:07:56Z

    Hi,

while hacking on pg_verify_checksums and looking at hexdumps, I noticed
that the TAP tests of pg_verify_checksums (and pg_basebackup from which
it was copy-pasted) actually write "305c305c[...]" (i.e. literal
backslashes and number 0s) instead of "000[...]" into the to-be-
corrupted relfilenodes due to wrong quoting.

This also revealed a second bug in the pg_basebackup test suite where
the offset for the corruption in the second file was wrong, so it
actually never got corrupted, and the tests only passed due to the above
twice than expected number of written bytes. The write() probably
overflowed into an adjacent block so that the total number of corrupted
blocks was as expected by addident. Oops, my bad, patch attached.


Michael

-- 
Michael Banck
Projektleiter / Senior Berater
Tel.: +49 2166 9901-171
Fax:  +49 2166 9901-100
Email: michael.banck@credativ.de

credativ GmbH, HRB Mönchengladbach 12080
USt-ID-Nummer: DE204566209
Trompeterallee 108, 41189 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer

Unser Umgang mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz

  2. Re: [Patch] checksumming-related buglets in pg_verify_checksums/pg_basebackup TAP tests

    Michael Paquier <michael@paquier.xyz> — 2019-02-18T05:25:03Z

    On Thu, Feb 14, 2019 at 03:07:56PM +0100, Michael Banck wrote:
> This also revealed a second bug in the pg_basebackup test suite where
> the offset for the corruption in the second file was wrong, so it
> actually never got corrupted, and the tests only passed due to the above
> twice than expected number of written bytes. The write() probably
> overflowed into an adjacent block so that the total number of corrupted
> blocks was as expected by accident. Oops, my bad, patch attached.

Fixed and back-patched where adapted, thanks!  ee9e145 was a first
shot for a fix in pg_basebackup tests, but it has missed one seek()
call.
--
Michael