t/010_pg_basebackup.pl checksum verify fails with RELSEG_SIZE 1 - Mailing list pgsql-hackers

From Thomas Munro
Subject t/010_pg_basebackup.pl checksum verify fails with RELSEG_SIZE 1
Date
Msg-id CA+hUKGLEbeSxoFw43MH8i=snMY_MMM5+PnhBuexRqTVrDc-g2A@mail.gmail.com
Whole thread Raw
Responses Re: t/010_pg_basebackup.pl checksum verify fails with RELSEG_SIZE 1  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

Sometimes I set RELSEG_SIZE to 1, as a way to get the various in-tree
tests to give the relation segment code a good workout.  That's
outside the range that configure --with-segsize would allow and
therefore not really a supported size (it's set in GB), but it's very
useful for giving the relation segment code a good workout on small
databases like the check-world ones.  At some point I think that
worked, but now it says:

t/010_pg_basebackup.pl ... 100/106
#   Failed test 'pg_basebackup does not report more than 5 checksum
mismatches stderr
/(?^s:^WARNING.*further.*failures.*will.not.be.reported)/'
#   at t/010_pg_basebackup.pl line 526.
#                   'WARNING:  checksum verification failed in file
"./base/13759/16396", block 0: calculated 49B8 but expected A91E
# WARNING:  could not verify checksum in file "./base/13759/16396",
block 4: read buffer size 8225 and page size 8192 differ
# pg_basebackup: error: checksum error occurred
# '
#     doesn't match '(?^s:^WARNING.*further.*failures.*will.not.be.reported)'

I haven't quite figured out why it does that yet (I don't see any
files of size other than 0 or 8192, as expected), but it'd be nice to
do that.  I was even thinking of running a bf animal that way.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (andmore?)
Next
From: Tom Lane
Date:
Subject: Re: t/010_pg_basebackup.pl checksum verify fails with RELSEG_SIZE 1