Horton

Re: new heapcheck contrib module

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>, Amul Sul <sulamul@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-08-06T16:43:17Z
Lists: pgsql-hackers 
On Wed, Aug 5, 2020 at 4:36 PM Peter Geoghegan <pg@bowt.ie> wrote:
> Right, but the professional exterminator can be expected to use expert
> level tools, where a great deal of technical sophistication is
> required to interpret what's going on sensibly. An amatuer can only
> use them to determine if something is wrong at all, which is usually
> not how they add value.

Quite true.

> I myself seem to have had quite different experiences with corruption,
> presumably because it happened at product companies like Heroku. I
> tended to find software bugs (e.g. the one fixed by commit 008c4135)
> that were rare and novel by casting a wide net over a large number of
> relatively homogenous databases. Whereas your experiences tend to
> involve large support customers with more opportunity for operator
> error. Both perspectives are important.

I concur.

> I wrote my own expert level tool, pg_hexedit. I have to admit that the
> level of interest in that tool doesn't seem to be all that great,
> though I myself have used it to investigate corruption to great
> effect. But I suppose there is no way to know how it's being used.

I admit not to having tried pg_hexedit, but I doubt that it would help
me very much outside of my own development work. The problem is that
in a typical case I am trying to help someone in a professional
capacity without access to their machines, and without knowledge of
their environment or data. Moreover, sometimes the person I'm trying
to help is an unreliable narrator. I can ask people to run tools they
have and send the output, and then I can look at that output and tell
them what to do next. But it has to be a tool they have (or they can
easily get) and it can't involve any complicated if-then stuff.
Something like "if the page is totally garbled then do X but if it
looks mostly OK then do Y" is radically out of reach. They have no
clue about that. Hence my interest in tools that automate as much of
the investigation as may be practical.

We're probably beating this topic to death at this point; I don't
think we are really in any sort of meaningful disagreement, and the
next steps in this particular case seem clear enough.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

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.