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.
regards, tom lane