I don't think that you can tell from the "verbose" listing whether any pages were skipped because they were known to contain only visible tuples.
I think that it will only vacuum pages flagged as "all visible" if it decides to freeze tuples in the table, either because of approaching transaction wraparound or because you explicitly ran VACUUM
with the FREEZE
option. (If you use the vacuumdb
command-line executable, this is the -F
option.)
In our shop we supplement the autovacuum activity with a scheduled VACUUM FREEZE ANALYZE
on the database during non-peak hours. That minimizes the overhead of autovacuum during peak hours, and slightly improves query performance, because visibility checks are simpler.
I was able to figure out which file in the database storage was the culprit, by copying all the files to /dev/null.
cp -vR /usr/lib/postgresql/8.4 /dev/null
(The path to your DB files might differ)
The currupt file could not be copied, but there was nothing I could do to change that. (so it was most probably a FS error or hardware failure)
So I restarted the server with a forced fsck (e.g. touch /forcefsck
), to make sure the FS would do the best to fix itself. This might not be the way you'll want to go, since it is possible to have a total data loss afterwards, but I was able to preserve the most precious data already beforehand, so I took the risk.
After reboot I could finally access the inaccessable table again, but I am not sure, if the data contained is corrupted or not. Anyway, I do have a backup now, which I can disect to find out, and my server can go back online for now...
I recommend reading the wiki of postgres about corruption and the slides of this FOSDEM presentation for some more info on DB corruption
Best Answer
You cannot do that. Use one of the other formats; ideally the
custom
format, which is automatically compressed.