From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Mark Dilger <mark.dilger@enterprisedb.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: Wed, 13 May 2020 18:10:51 -0400
Message-ID: <20200513221051.GA26592@alvherre.pgsql> (raw)
In-Reply-To: <CAH2-Wz=AnzG_KvoR-KairFaZJavSzzDKfv2h30aJxM=RYxuUTg@mail.gmail.com>
On 2020-May-12, Peter Geoghegan wrote:
> > The point is that when checking the table for corruption I avoid
> > calling anything that might assert (or segfault, or whatever).
>
> I don't think that you can expect to avoid assertion failures in
> general.
Hmm. I think we should (try to?) write code that avoids all crashes
with production builds, but not extend that to assertion failures.
Sticking again with the provided example,
> I'll stick with your example. You're calling
> TransactionIdDidCommit() from check_tuphdr_xids(), which will
> interrogate the commit log and pg_subtrans. It's just not under your
> control.
in a production build this would just fail with an error that the
pg_xact file cannot be found, which is fine -- if this happens in a
production system, you're not disturbing any other sessions. Or maybe
the file is there and the byte can be read, in which case you would get
the correct response; but that's fine too.
I don't know to what extent this is possible.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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: alvherre@2ndquadrant.com, pg@bowt.ie, mark.dilger@enterprisedb.com, robertmhaas@gmail.com, andres@anarazel.de
Subject: Re: new heapcheck contrib module
In-Reply-To: <20200513221051.GA26592@alvherre.pgsql>
* 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