Re: new heapcheck contrib module

> On Oct 22, 2020, at 2:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> I wrote:
>> Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)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 will be LP_NORMAL vs LP_REDIRECT? I was thinking it was LP_DEAD vs LP_REDIRECT, as the little endian platforms are seeing corruption messages about bad redirect line pointers, and the big-endian are apparently skipping over the line pointer entirely, which makes sense if it is LP_DEAD but not if it is LP_NORMAL. It would also skip over LP_UNUSED, but I don't see how that could be stored in lp_flags, because 0x77 is going to either be 01110111 or 11101110, and in neither case do you get two zeros adjacent, but you could get two ones adjacent. (LP_UNUSED = binary 00 and LP_DEAD = binary 11)

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