Re: pg_amcheck contrib application

On Thu, Mar 11, 2021 at 3:12 AM Peter Eisentraut
<peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
> (I'm still not a fan of adding more client-side tools whose sole task is
> to execute server-side functionality in a slightly filtered way, but it
> seems people are really interested in this, so ...)
>
> I want to register, if we are going to add this, it ought to be in
> src/bin/. If we think it's a useful tool, it should be there with all
> the other useful tools.

I think this provides a pretty massive gain in usability. If you
wanted to check all of your tables and btree indexes without this, or
worse yet some subset of them that satisfied certain criteria, it
would be a real nuisance. You don't want to run all of the check
commands in a single transaction, because that keeps snapshots open,
and there's a good chance you do want to use parallelism. Even if you
ignore all that, the output you're going to get from running the
queries individually in psql is not going to be easy to sort through,
whereas the tool is going to distill that down to what you really need
to know.

Perhaps we should try to think of some way that some of these tools
could be unified, since it does seem a bit silly to have reindexdb,
vacuumdb, and pg_amcheck all as separate commands basically doing the
same kind of thing but for different maintenance operations, but I
don't think getting rid of them entirely is the way - and I don't
think that unifying them is a v14 project.

I also had the thought that maybe this should go in src/bin, because I
think this is going to be awfully handy for a lot of people. However,
I don't think there's a rule that binaries can't go in contrib --
oid2name and vacuumlo are existing precedents. But I guess that's only
2 out of quite a large number of binaries that we ship, so maybe it's
best not to add to it, especially for a tool which I at least suspect
is going to get a lot more use than either of those.

Anyone else want to vote for or against moving this to src/bin?

--
Robert Haas
EDB: http://www.enterprisedb.com