Horton

Re: new heapcheck contrib module

Mark Dilger <mark.dilger@enterprisedb.com>

View thread View on postgr.es
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Thomas Munro <thomas.munro@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Geoghegan <pg@bowt.ie>, "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Stephen Frost <sfrost@snowman.net>, Michael Paquier <michael@paquier.xyz>, Amul Sul <sulamul@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2021-02-24T18:55:28Z
Lists: pgsql-hackers

Attachments


> On Feb 24, 2021, at 10:40 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> 
> On Tue, Feb 23, 2021 at 12:38 PM Mark Dilger
> <mark.dilger@enterprisedb.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.

Commits

  1. Add pg_amcheck, a CLI for contrib/amcheck.

  2. Refactor and generalize the ParallelSlot machinery.

  3. Generalize parallel slot result handling.

  4. Move some code from src/bin/scripts to src/fe_utils to permit reuse.

  5. Factor pattern-construction logic out of processSQLNamePattern.

  6. Doc: clean up verify_heapam() documentation.

  7. Fix more portability issues in new amcheck code.

  8. Fix portability issues in new amcheck test.

  9. Try to avoid a compiler warning about using fxid uninitialized.

  10. Extend amcheck to check heap pages.

  11. Adjust walsender usage of xlogreader, simplify APIs

  12. Improve checking of child pages in contrib/amcheck.

  13. Sanitize line pointers within contrib/amcheck.

  14. Fix possible sorting error when aborting use of abbreviated keys.