Re: new heapcheck contrib module

> On May 13, 2020, at 5:36 PM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Wed, May 13, 2020 at 5:18 PM Mark Dilger
> <mark(dot)dilger(at)enterprisedb(dot)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 the regression test suite because it needed to be something other developers could read, verify, "yeah, I can see why that would be corruption, and would give an error message of the sort the test expects", and then could be run to verify that indeed 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 particular TAP test.

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