Re: new heapcheck contrib module

> On Oct 22, 2020, at 6:50 PM, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>
>
>
>> On Oct 22, 2020, at 6:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 with backslashes 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 curious about, that string corrupts on little endian machines but not big endian machines. If we want to have a test that tailors 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