Re: new heapcheck contrib module - Mailing list pgsql-hackers

> On Apr 29, 2020, at 11:41 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, Apr 22, 2020 at 10:43 PM Mark Dilger
> <mark.dilger@enterprisedb.com> wrote:
>> It's simple enough to extend the tap test a little to check for those things.  In v3, the tap test skips tests if
thepage size is not 8k, and also if the tuples do not fall on the page where expected (which would happen due to
alignmentissues, gremlins, or whatever.). 
>
> Skipping the test if the tuple isn't in the expected location sounds
> really bad. That will just lead to the tests passing without actually
> doing anything. If the tuple isn't in the expected location, the tests
> should fail.
>
>> There are other approaches, though.  The HeapFile/HeapPage/HeapTuple perl modules recently submitted on another
thread*could* be used here, but only if those modules are likely to be committed. 
>
> Yeah, I don't know if we want that stuff or not.
>
>> This test *could* be extended to autodetect the page size and alignment issues and calculate at runtime where tuples
willbe on the page, but only if folks don't mind the test having that extra complexity in it.  (There is a school of
thoughtthat regression tests should avoid excess complexity.). Do you have a recommendation about which way to go with
this?
>
> How much extra complexity are we talking about?

The page size is easy to query, and the test already does so, skipping if the answer isn't 8k.  The test could
recalculateoffsets based on the pagesize rather than skipping the test easily enough, but the MAXALIGN stuff is a
littleharder.  I don't know (perhaps someone would share?) how to easily query that from within a perl test.  So the
testcould guess all possible alignments that occur in the real world, read from the page at the offset that alignment
wouldcreate, and check if the expected datum is there.  The test would have to be careful to avoid false positives, by
placingdata before and after the datum being checked with bit patterns that cannot be misinterpreted as a match.  That
levelof complexity seems unappealing, at least to me.  It's not hard to write, but maintaining stuff like that is an
unwelcomeburden. 

> It feels to me like
> for a heap page, the only things that are going to affect the position
> of the tuples on the page -- supposing we know the tuple size -- are
> the page size and, I think, MAXALIGN, and that doesn't sound too bad.
> Another possibility is to use pageinspect's heap_page_items() to
> determine the position within the page (lp_off), which seems like it
> might simplify things considerably. Then, we're entirely relying on
> the backend to tell us where the tuples are, and we only need to worry
> about the offsets relative to the start of the tuple.
>
> I kind of like that approach, because it doesn't involve having Perl
> code that knows how heap pages are laid out; we rely entirely on the C
> code for that. I'm not sure if it'd be a problem to have a TAP test
> for one contrib module that uses another contrib module, but maybe
> there's some way to figure that problem out.

Yeah, I'll give this a try.

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