Re: new heapcheck contrib module

> On Feb 24, 2021, at 10:40 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Tue, Feb 23, 2021 at 12:38 PM Mark Dilger
> <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>> This is changed in v40 as you propose to exit on FATAL and PANIC level errors and on error to send a query. On lesser errors (which includes all corruption reports about btrees and some heap corruption related errors), the slot's connection is still useable, I think. Are there cases where the error is lower than FATAL and yet the connection needs to be reestablished? It does not seem so from the testing I have done, but perhaps I'm not thinking of the right sort of non-fatal error?
>
> I think you should assume that if you get an ERROR you can - and
> should - continue to use the connection, but still exit non-zero at
> the end. Perhaps one can contrive some scenario where that's not the
> case, but if the server does the equivalent of "ERROR: session
> permanently borked" we should really change those to FATAL; I think
> you can discount that possibility.

Ok, that's how I had it, so no changes necessary.

>> In v40, exit(1) means the program encountered fatal errors leading it to stop, and exit(2) means that a non-fatal error and/or corruption reports occurred somewhere during the processing. Otherwise, exit(0) means your database was successfully checked and is healthy.

Other changes in v40 per our off-list discussions but not related to your on-list review comments:

Removed option --no-tables.

Removed option --no-dependents. This was a synonym for the combination of --exclude-toast and --exclude-indexes, but having such a synonym isn't all that helpful.

Renamed --exclude-toast to --no-toast-expansion and changed its behavior a bit. Likewise, renamed --exclude-indexes to --no-index-expansion and change behavior. The behavioral changes are that these options now only have the effect of not automatically expanding the list of relations to check to include toast or indexes associated with relations already in the list. The prior names didn't exclusively mean that, and the behavior didn't exclusively do that.

Updated the docs per your other review email.

Implemented --progress to behave much more like how it does in pg_basebackup.