Re: amcheck assert failure

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Grigory Smolkin <g(dot)smolkin(at)postgrespro(dot)ru>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: amcheck assert failure
Date: 2019-04-24 20:15:12
Message-ID: CAH2-WzkotO_ueP55Up2ZfHi+JehzgkU5rCH3WiQ6q3kNo+G1nw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Mon, Apr 22, 2019 at 1:35 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 Content-Type Size
0001-Sanitize-line-pointers-within-contrib-amcheck.patch application/octet-stream 12.4 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tomas Vondra 2019-04-24 21:17:50 Re: CREATE SUBSCRIPTION fails with long passwords
Previous Message PG Bug reporting form 2019-04-24 19:42:51 BUG #15778: Replication slot peak query cause memory spike at the server when big transaction are running