Re: new heapcheck contrib module

> On Oct 22, 2020, at 2:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> I wrote:
>> Mark Dilger <mark.dilger@enterprisedb.com> writes:
>>> It is seeking to position 32 and writing '\x77\x77\x77\x77'.  x86_64 is
>>> little-endian, and ppc32 and sparc64 are both big-endian, right?
>
>> They are, but that should not meaningfully affect the results of
>> that corruption step.  You zapped only one line pointer not
>> several, but it would look the same regardless of endiannness.
>
> Oh, wait a second.  ItemIdData has the flag bits in the middle:
>
> typedef struct ItemIdData
> {
>    unsigned    lp_off:15,        /* offset to tuple (from start of page) */
>                lp_flags:2,       /* state of line pointer, see below */
>                lp_len:15;        /* byte length of tuple */
> } ItemIdData;
>
> meaning that for that particular bit pattern, one endianness
> is going to see the flags as 01 (LP_NORMAL) and the other as 10
> (LP_REDIRECT).  The offset/len are corrupt either way, but
> I'd certainly expect that amcheck would produce different
> complaints about those two cases.  So it's unsurprising if
> this test case's output is endian-dependent.

Well, the issue is that on big-endian machines it is not reporting any corruption at all.  Are you sure the difference
willbe LP_NORMAL vs LP_REDIRECT?  I was thinking it was LP_DEAD vs LP_REDIRECT, as the little endian platforms are
seeingcorruption messages about bad redirect line pointers, and the big-endian are apparently skipping over the line
pointerentirely, which makes sense if it is LP_DEAD but not if it is LP_NORMAL.  It would also skip over LP_UNUSED, but
Idon't see how that could be stored in lp_flags, because 0x77 is going to either be 01110111 or 11101110, and in
neithercase do you get two zeros adjacent, but you could get two ones adjacent.  (LP_UNUSED = binary 00 and LP_DEAD =
binary11) 

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