Re: amcheck (B-Tree integrity checking tool)

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Kevin Grittner <kgrittn(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
Subject: Re: amcheck (B-Tree integrity checking tool)
Date: 2016-11-22 18:56:07
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Sun, Nov 20, 2016 at 3:42 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> OK. If it's not reasonable to continue checking after an ERROR, then
> I think ERROR is the way to go. If somebody really doesn't like that
> lack of flexibility (in either direction), they can propose a change
> later for separate consideration. That limitation is not, in my view,
> a sufficient reason to hold up the patch on the table.

I attach V4 of amcheck. I decided to leave things as they are, as far
as forcing a different elevel goes (you still need to modify a macro).
I didn't change the elevel macro from CONCERN in a couple of cases, as
Andres suggested, because in fact that's generally the same as DEBUG1,
not WARNING (I agreed with Andres that it was WARNING before, but it
isn't unless you #define NOT_USED).

Andres said: "Theoretically we should recheck that the oids still
match, theoretically the locking here allows the index->table mapping
to change". I don't know how to act on this feedback, since comparable
index + heap locking code should have the same problem, but doesn't
consider it. How is this any different to reindex_index()?

Other than that, all feedback items were worked through. I made the
functions PARALLEL SAFE, too, since I noticed that that wasn't the
case in passing.

Peter Geoghegan

Attachment Content-Type Size
0001-Add-amcheck-extension-to-contrib.patch text/x-patch 60.7 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-11-22 19:28:46 Re: condition variables
Previous Message Tom Lane 2016-11-22 18:47:31 Re: [HACKERS] switching documentation build to XSLT