> 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.
Yeah, I'm already looking at that. The logic in verify_heapam skips over line pointers that are unused or dead, and
thetest is reporting zero corruption (and complaining about that), so it's probably not going to help to overwrite all
theline pointers with this particular bit pattern any more than to just overwrite the first one, as it would just skip
themall.
I think the test should overwrite the line pointers with a variety of different bit patterns, or one calculated to work
onall platforms. I'll have to write that up.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
