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

From Mark Dilger
Subject Re: new heapcheck contrib module
Date
Msg-id 85BE72E5-A926-4F23-9FD5-64239C0C6BA5@enterprisedb.com
Whole thread Raw
In response to Re: new heapcheck contrib module  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: new heapcheck contrib module
Re: new heapcheck contrib module
List pgsql-hackers

> On Oct 26, 2020, at 7:08 AM, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
>
>
>
>> On Oct 26, 2020, at 7:00 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> On Mon, Oct 26, 2020 at 9:56 AM Mark Dilger
>> <mark.dilger@enterprisedb.com> wrote:
>>> Much of the test in 0002 could be ported to work without committing the rest of 0002, if the pg_amcheck command
lineutiilty is not wanted. 
>>
>> How much consensus do we think we have around 0002 at this point? I
>> think I remember a vote in favor and no votes against, but I haven't
>> been paying a whole lot of attention.
>
> My sense over the course of the thread is that people were very much in favor of having heap checking functionality,
butquite vague on whether they wanted the command line interface.  I think the interface is useful, but I'd rather hear
fromothers on this list whether it is useful enough to justify maintaining it.  As the author of it, I'm biased.
Hopefullyothers with a more objective view of the matter will read this and vote? 
>
> I don't recall patches 0003 through 0005 getting any votes.  0003 and 0004, which create and use a non-throwing
interfaceto clog, were written in response to Andrey's request, so I'm guessing that's kind of a vote in favor.  0005
wasfactored out of of 0001 in response to a lack of agreement about whether verify_heapam should have acl checks.  You
seemedin favor, and Peter against, but I don't think we heard other opinions. 

The v20 patches 0002, 0003, and 0005 still apply cleanly, but 0004 required a rebase.  (0001 was already committed last
week.)

Here is a rebased set of 4 patches, numbered 0002..0005 to be consistent with the previous naming.  There are no
substantialchanges. 



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




Attachment

pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: MultiXact\SLRU buffers configuration
Next
From: Tom Lane
Date:
Subject: Re: new heapcheck contrib module