Re: new heapcheck contrib module

> On Oct 22, 2020, at 6:50 PM, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
>
>
>
>> On Oct 22, 2020, at 6:46 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> I wrote:
>>> I get
>>> off = 7777, flags = 2, len = 3bbb
>>> on a little-endian machine, and
>>> off = 3bbb, flags = 2, len = 7777
>>> on big-endian.  It'd be less symmetric if the bytes weren't
>>> all the same ...
>>
>> ... but given that this is the test value we are using, why
>> don't both endiannesses whine about a non-maxalign'd offset?
>> The code really shouldn't even be trying to follow these
>> redirects, because we risk SIGBUS on picky architectures.
>
> Ahh, crud.  It's because
>
>     syswrite($fh, '\x77\x77\x77\x77', 500)
>
> is wrong twice.  The 500 was wrong, but the string there isn't the bit pattern we want -- it's just a string literal
withbackslashes and such.  It should have been double-quoted. 

The reason this never came up in testing is what I was talking about elsewhere -- this test isn't designed to create
*specific*corruptions.  It's just supposed to corrupt the table in some random way.  For whatever reasons I'm not too
curiousabout, that string corrupts on little endian machines but not big endian machines.  If we want to have a test
thattailors very specific corruptions, I don't think the way to get there is by debugging this test. 

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