> On Oct 22, 2020, at 1:31 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
> Mark Dilger <mark.dil...@enterprisedb.com> writes:
>>> On Oct 22, 2020, at 1:09 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> ooh, looks like prairiedog sees the problem too. That means I should be
>>> able to reproduce it under a debugger, if you're not certain yet where
>>> the problem lies.
>
>> Thanks, Tom, but I question whether the regression test failures are from a
>> problem in the verify_heapam.c code. I think they are a busted perl test.
>> The test was supposed to corrupt the heap by overwriting a heap file with a
>> large chunk of garbage, but in fact only wrote a small amount of garbage.
>> The idea was to write about 2000 bytes starting at offset 32 in the page, in
>> order to corrupt the line pointers, but owing to my incorrect use of
>> syswrite in the perl test, that didn't happen.
>
> Hm, but why are we seeing the failure only on specific machine
> architectures? sparc64 and ppc32 is a weird pairing, too.
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?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
