On Mon, Jun 6, 2016 at 11:44 AM, Andres Freund <and...@anarazel.de> wrote: >> In terms of diagnostic tools, you can get the VM bits and >> page-level bits using the pg_visibility extension; I wrote it >> precisely because of concerns like the ones you raise here. If you >> want to cross-check the page-level bits against the tuple-level bits, >> you can do that with the pageinspect extension. And if you do those >> things, you can actually find out whether stuff is broken. > > That's WAY out ouf reach of any "normal users". Adding a vacuum option > is doable, writing complex queries is not.
Why would they have to write the complex query? Wouldn't they just need to run that we wrote for them? I mean, I'm not 100% dead set against this option you want, but in all honestly, I would never, ever tell anyone to use it. Unleashing VACUUM on possibly-damaged data is just asking it to decide to prune away tuples you don't want gone. I would try very hard to come up with something to give that user that was only going to *read* the possibly-damaged data with as little chance of modifying or erasing it as possible. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
