Re: corruption issue after server crash - ERROR: unexpected chunk number 0

Mike Broers <mbroers(at)gmail(dot)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