Re: pg_amcheck contrib application

> On Mar 12, 2021, at 11:24 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Fri, Mar 12, 2021 at 2:05 PM <er(at)xs4all(dot)nl> wrote:
>> I think there is a formatting glitch in lines like:
>>
>> 2/4 relations (50%) 187977/187978 pages (99%), (testdb )
>>
>> I suppose that last part should show up trimmed as '(testdb)', right?
>
> Actually I think this is intentional. The idea is that as the line is
> rewritten we don't want the close-paren to move around. It's the same
> thing pg_basebackup does with its progress reporting.
>
> Now that is not to say that some other behavior might not be better,
> just that Mark was copying something that already exists, probably
> because he knows that I'm finnicky about consistency....

I think Erik's test case only checked one database, which might be why it looked odd to him. But consider:

pg_amcheck -d foo -d bar -d myreallylongdatabasename -d myshortername -d baz --progress

The tool will respect your database ordering, and check foo, then bar, etc. If you have --jobs greater than one, it will start checking some relations in bar before finishing all relations in foo, but with a fudge factor, pg_amcheck can report that the processing has moved on to database bar, etc.

You wouldn't want the parens to jump around when the long database names get processed. So it keeps the parens in the same location, space pads shorter database names, and truncates overlong database names.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company