Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: new heapcheck contrib module
From: Mark Dilger <mark.dilger@enterprisedb.com>
In-Reply-To: 
 <CAH2-Wzkam3w_nSjQ78KtMODeonwfnq5fjsBpi8jH-Lsjrcr-ag@mail.gmail.com>
Date: Thu, 14 May 2020 08:35:03 -0700
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
 Robert Haas <robertmhaas@gmail.com>,
 Andres Freund <andres@anarazel.de>,
 PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2CC5AAF7-E6DB-42E8-91DC-0C6E88FEBC3D@enterprisedb.com>
References: 
 <CAH2-Wz=AnzG_KvoR-KairFaZJavSzzDKfv2h30aJxM=RYxuUTg@mail.gmail.com>
 <20200513221051.GA26592@alvherre.pgsql>
 <CAH2-WzmBB4-Fr8_qz7faEe8s=5wzyUrNrbxdaeJesTvjp+5TEg@mail.gmail.com>
 <4D704A12-2546-4789-90B0-B0445BFC717B@enterprisedb.com>
 <CAH2-Wzkam3w_nSjQ78KtMODeonwfnq5fjsBpi8jH-Lsjrcr-ag@mail.gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Precedence: bulk


> On May 13, 2020, at 5:36 PM, Peter Geoghegan <pg@bowt.ie> wrote:
>=20
> 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.
>=20
> 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.=20


>> I think this is a misrepresentation of the tests that I've been =
running.
>=20
> 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.=20

>> There are two kinds of tests that I have done:
>>=20
>> 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.
>=20
> 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.

=E2=80=94
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company