> On Oct 23, 2020, at 11:04 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> I wrote:
>> Mark Dilger <mark.dil...@enterprisedb.com> writes:
>>> The patch I *should* have attached last night this time:
>
>> Thanks, I'll do some big-endian testing with this.
>
> Seems to work, so I pushed it (after some compulsive fooling
> about with whitespace and perltidy-ing).
Thanks for all the help!
> It appears to me that
> the code coverage for verify_heapam.c is not very good though,
> only circa 50%. Do we care to expend more effort on that?
Part of the issue here is that I developed the heapcheck code as a sequence of
patches, and there is much greater coverage in the tests in the 0002 patch,
which hasn't been committed yet. (Nor do I know that it ever will be.) Over
time, the patch set became:
0001 -- adds verify_heapam.c to contrib/amcheck, with basic test coverage
0002 -- adds pg_amcheck command line interface to contrib/pg_amcheck, with more
extensive test coverage
0003 -- creates a non-throwing interface to clog
0004 -- uses the non-throwing clog interface from within verify_heapam
0005 -- adds some controversial acl checks to verify_heapam
Your question doesn't have much to do with 3,4,5 above, but it definitely
matters whether we're going to commit 0002. The test in that patch, in
contrib/pg_amcheck/t/004_verify_heapam.pl, does quite a bit of bit twiddling of
heap tuples and toast records and checks that the right corruption messages
come back. Part of the reason I was trying to keep 0001's
t/001_verify_heapam.pl test ignorant of the exact page layout information is
that I already had this other test that covers that.
So, should I port that test from (currently non-existant) contrib/pg_amcheck
into contrib/amcheck, or should we wait to see if the 0002 patch is going to
get committed?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company