pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: new heapcheck contrib module
Date: Thu, 14 May 2020 08:35:03 -0700
Message-ID: <2CC5AAF7-E6DB-42E8-91DC-0C6E88FEBC3D@enterprisedb.com> (raw)
In-Reply-To: <CAH2-Wzkam3w_nSjQ78KtMODeonwfnq5fjsBpi8jH-Lsjrcr-ag@mail.gmail.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>



> 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 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








view thread (218+ messages)  latest in thread

Message-ID: <2CC5AAF7-E6DB-42E8-91DC-0C6E88FEBC3D@enterprisedb.com>
Permalink:  ../2CC5AAF7-E6DB-42E8-91DC-0C6E88FEBC3D@enterprisedb.com/
Also on:    postgresql.org/message-id/2CC5AAF7-E6DB-42E8-91DC-0C6E88FEBC3D@enterprisedb.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: mark.dilger@enterprisedb.com, pg@bowt.ie, alvherre@2ndquadrant.com, robertmhaas@gmail.com, andres@anarazel.de
  Subject: Re: new heapcheck contrib module
  In-Reply-To: <2CC5AAF7-E6DB-42E8-91DC-0C6E88FEBC3D@enterprisedb.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox