Re: btreecheck extension - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: btreecheck extension
Date
Msg-id CAM3SWZQ_69d+D+P1j=bafy3d8OpnmpgCbkWoma09OiTiP1exuQ@mail.gmail.com
Whole thread Raw
In response to Re: btreecheck extension  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: btreecheck extension  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Jun 17, 2014 at 1:16 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> I don't feel qualified to comment on any of the substantive issues you
> raise, so instead I'd like to bikeshed the name.  I suggest that we
> create one extension to be a repository for index-checking machinery
> (and perhaps also heap-checking machinery) and view this as the first
> of possibly several checkers to live there.  Otherwise, we may
> eventually end up with separate extensions for btreecheck, hashcheck,
> gistcheck, gincheck, spgistcheck, minmaxcheck, vodkacheck, heapcheck,
> toastcheck, etc. which seems like excessive namespace pollution.

I agree.

I hope that we'll eventually be able to move code like this into each
AM, with something like an amverifyintegrity pg_am entry optionally
provided. There'd also be a utility statement that would perform this
kind of verification. It seems natural to do this, as the patch I've
posted arguably adds a big modularity violation. Besides, it seems
worthwhile to pepper the regular regression tests with calls like
these, at least in some places, and putting something in core is the
most convenient way to do that.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Doing better at HINTing an appropriate column within errorMissingColumn()
Next
From: Kevin Grittner
Date:
Subject: Re: Doing better at HINTing an appropriate column within errorMissingColumn()