Re: amcheck assert failure - Mailing list pgsql-bugs

From Peter Geoghegan
Subject Re: amcheck assert failure
Date
Msg-id CAH2-WzkotO_ueP55Up2ZfHi+JehzgkU5rCH3WiQ6q3kNo+G1nw@mail.gmail.com
Whole thread Raw
In response to Re: amcheck assert failure  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Mon, Apr 22, 2019 at 1:35 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.)

Attached is a draft patch that adds a PageGetItemId() wrapper called
PageGetItemIdCareful(), and has amcheck use it consistently. This does
two basic sanity checks that seem very likely to avoid the kind of
misbehaviors that result in a crash (including assertion failures)
when amcheck is used.

This is a bit more complicated than I'd hoped, because it is necessary
to call PageGetItemIdCareful() before _bt_compare() and other core
code in a way that wouldn't quite look right with raw PageGetItemId()
calls. _bt_compare() will do its own PageGetItemId(), and will itself
assert !bt_check_natts() (which was the issue in Grigory's problem
report), so we need to make sure that that will be safe ahead of time.
Even still, it doesn't seem too complicated to me.

-- 
Peter Geoghegan

Attachment

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #15778: Replication slot peak query cause memory spike at the server when big transaction are running
Next
From: Tomas Vondra
Date:
Subject: Re: CREATE SUBSCRIPTION fails with long passwords