From: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
---|---|
To: | Mike Broers <mbroers(at)gmail(dot)com> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: corruption issue after server crash - ERROR: unexpected chunk number 0 |
Date: | 2013-11-22 19:54:06 |
Message-ID: | 1385150046.18785.YahooMailNeo@web162902.mail.bf1.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-11-22 20:13:33 | Re: pg_upgrade ?deficiency |
Previous Message | Kevin Grittner | 2013-11-22 19:24:05 | Re: Puzzling table scan in a CTE |