Re: amcheck assert failure - Mailing list pgsql-bugs

From Tom Lane
Subject Re: amcheck assert failure
Date
Msg-id 25618.1555965356@sss.pgh.pa.us
Whole thread Raw
In response to Re: amcheck assert failure  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: amcheck assert failure  (Peter Geoghegan <pg@bowt.ie>)
Re: amcheck assert failure  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-bugs
Peter Geoghegan <pg@bowt.ie> writes:
> On Mon, Apr 22, 2019 at 12:51 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Nonetheless ... do we really want an assertion failure rather than
>> some more-mundane error report?  Seems like the point of amcheck
>> is to detect data corruption, so I'd rather get an ERROR than an
>> assertion (which would not fire in production builds anyway).

> The only explanation I can think of is that the assertion failure was
> from the core code

That's what I guessed.  It might be impractical for amcheck to prevent it,
but we should try to find out.

> We could:
> * Throw an error when any line item reports lp_len == 0.
> * Throw an error when there is a line item that's either LP_UNUSED, or
> LP_REDIRECT. The corrupt page sent by Grigory had both.
> What do you think of the idea of committing some simple checks to do
> this with contrib/amcheck on v12?

No objection here, as long as it doesn't add an unreasonable amount
of complexity.  (If it does, we might have to think harder about
what to do.)

            regards, tom lane



pgsql-bugs by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: amcheck assert failure
Next
From: "Jonathan S. Katz"
Date:
Subject: Re: Possible to store invalid SCRAM-SHA-256 Passwords