Re: new heapcheck contrib module - Mailing list pgsql-hackers

From Tom Lane
Subject Re: new heapcheck contrib module
Date
Msg-id 41702.1603398719@sss.pgh.pa.us
Whole thread Raw
In response to Re: new heapcheck contrib module  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: new heapcheck contrib module  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers
Mark Dilger <mark.dilger@enterprisedb.com> writes:
>> On Oct 22, 2020, at 1:09 PM, Tom Lane <tgl@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
thinkthey are a busted perl test.  The test was supposed to corrupt the heap by overwriting a heap file with a large
chunkof garbage, but in fact only wrote a small amount of garbage.  The idea was to write about 2000 bytes starting at
offset32 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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Mark Dilger
Date:
Subject: Re: new heapcheck contrib module
Next
From: Mark Dilger
Date:
Subject: Re: new heapcheck contrib module