Re: new heapcheck contrib module

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Stephen Frost <sfrost(at)snowman(dot)net>, Michael Paquier <michael(at)paquier(dot)xyz>, Amul Sul <sulamul(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: new heapcheck contrib module
Date: 2020-10-22 20:31:59
Message-ID: 41702.1603398719@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> writes:
>> On Oct 22, 2020, at 1:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Dilger 2020-10-22 20:39:15 Re: new heapcheck contrib module
Previous Message Mark Dilger 2020-10-22 20:31:04 Re: new heapcheck contrib module