Re: new heapcheck contrib module

> On May 13, 2020, at 5:36 PM, Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Wed, May 13, 2020 at 5:18 PM Mark Dilger
> <mark.dilger@enterprisedb.com> wrote:
>> I am not removing any assertions.  I do not propose to remove any assertions. When I talk about "hardening against
assertions",that is not in any way a proposal to remove assertions from the code. 
>
> I'm sorry if I seemed to suggest that you wanted to remove assertions

Not a problem at all.  As always, I appreciate your involvement in this code and design review.


>> I think this is a misrepresentation of the tests that I've been running.
>
> I didn't actually mean it that way, but I can see how my words could
> reasonably be interpreted that way. I apologize.

Again, no worries.

>> There are two kinds of tests that I have done:
>>
>> First, there is the regression tests, t/004_verify_heapam.pl, which is obviously contrived.  That was included in
theregression test suite because it needed to be something other developers could read, verify, "yeah, I can see why
thatwould be corruption, and would give an error message of the sort the test expects", and then could be run to verify
thatindeed that expected error message was generated. 
>
> I still don't think that this is necessary. It could work for one type
> of corruption, that happens to not have any of the problems, but just
> testing that one type of corruption seems rather arbitrary to me.

As discussed with Robert off list, this probably doesn't matter.  The patch can be committed with or without this
particularTAP test. 

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