Mike Broers <mbro...@gmail.com> wrote: > vacuumb avz, pg_dumpall, and vacuum freeze analyze on the former > standby database that received the corruption via replication all > came back without errors. Is the vacuum freeze intended to > potentially fix problems or just reveal if other tables may have > corruption, Im trying to decide if this needs to be run in > production.
You do know that you could cause the vacuumdb run to freeze by adding the F option, right? Anyway, there are two reasons I would run VACUUM FREEZE (or use the F option): (1) The vacuum will pass every page in each table, rather than just visiting pages which are not known to be all-visible already, so it is more likely to find any corruption that is there. You kinda have that covered anyway with the pg_dumpall run, though. (2) The freezing, which then releases no-longer-needed clog space at the next checkpoint, has been known to dodge some bad transaction ID / visibility problems. The odds that it will fix existing corruption are very slim, but non-zero. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
