Re: new heapcheck contrib module

> On Oct 23, 2020, at 11:04 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
>> Mark Dilger <mark.dilger@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
coveragein 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.
Thetest in that patch, in contrib/pg_amcheck/t/004_verify_heapam.pl, does quite a bit of bit twiddling of heap tuples
andtoast records and checks that the right corruption messages come back.  Part of the reason I was trying to keep
0001'st/001_verify_heapam.pl test ignorant of the exact page layout information is that I already had this other test
thatcovers that. 

So, should I port that test from (currently non-existant) contrib/pg_amcheck into contrib/amcheck, or should we wait to
seeif the 0002 patch is going to get committed? 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company