Re: new heapcheck contrib module

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: new heapcheck contrib module
Date: 2020-05-14 18:43:14
Message-ID: CA+TgmoaLUS27N0Ye5pcb7-GQuib3Ds_ZzM1qckgNjp6aSjWgvA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 13, 2020 at 7:32 PM Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> I agree that this (a test tool that exercises our code against
> arbitrarily corrupted data pages) is not going to work as a test that
> all buildfarm members run -- it seems something for specialized
> buildfarm members to run, or even something that's run outside of the
> buildfarm, like sqlsmith. Obviously such a tool would not be able to
> run against an assertion-enabled build, and we shouldn't even try.

I have a question about what you mean here by "arbitrarily."

If you mean that we shouldn't have the buildfarm run the proposed heap
corruption checker against heap pages full of randomly-generated
garbage, I tend to agree. Such a test wouldn't be very stable and
might fail in lots of low-probability ways that could require
unreasonable effort to find and fix.

If you mean that we shouldn't have the buildfarm run the proposed heap
corruption checker against any corrupted heap pages at all, I tend to
disagree. If we did that, then we'd basically be releasing a heap
corruption checker with very limited test coverage. Like, we shouldn't
only have negative test cases, where the absence of corruption
produces no results. We should also have positive test cases, where
the thing finds some problem...

At least, that's what I think.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-05-14 18:52:06 Re: SLRU statistics
Previous Message Ranier Vilela 2020-05-14 18:37:32 Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData)