Re: amcheck (B-Tree integrity checking tool) - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: amcheck (B-Tree integrity checking tool)
Date
Msg-id CAM3SWZRpuN35ia+kOUqjafSo6=TA8POqzoUWOMPW7DH+LhEj9g@mail.gmail.com
Whole thread Raw
In response to Re: amcheck (B-Tree integrity checking tool)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] amcheck (B-Tree integrity checking tool)  (Andres Freund <andres@anarazel.de>)
Re: [HACKERS] amcheck (B-Tree integrity checking tool)  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Sun, Nov 20, 2016 at 3:42 PM, Robert Haas <robertmhaas@gmail.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

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: [RFC] Should we fix postmaster to avoid slow shutdown?
Next
From: Robert Haas
Date:
Subject: Re: condition variables