Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks, after this pg_dumpall I am going to see what kind of impact I can expect from running VACUUM FREEZE ANALYZE (normally I just run vacuumdb -avz nightly via a cron job) and schedule time to run this in production against all the tables in the database.  Is there anything I should look out for with vacuum freeze?

Much appreciated,
Mike


On Thu, Nov 21, 2013 at 4:51 PM, Kevin Grittner <kgrittn@xxxxxxxxx> wrote:
Mike Broers <mbroers@xxxxxxxxx> wrote:

> Thanks for the response.  fsync and full_page_writes are both on.

> [ corruption appeared following power loss on the machine hosing
> the VM running PostgreSQL ]

That leaves three possibilities:
  (1)  fsync doesn't actually guarantee persistence in your stack.
  (2)  There is a hardware problem which has not been recognized.
  (3)  There is a so-far unrecognized bug in PostgreSQL.

Based on my personal experience, those are listed in descending
order of probability.  I seem to recall reports of some VM for
which an fsync did not force data all the way to persistent
storage, but I don't recall which one.  You might want to talk to
your service provider about what guarantees they make in this
regard.

> Is there something else I can run to confirm we are more or less
> ok at the database level after the pg_dumpall or is there no way
> to be sure and a fresh initdb is required.

Given that you had persistence options in their default state of
"on", and the corruption appeared after a power failure in a VM
environment, I would guess that the damage is probably limited.
That said, damage from this sort of event can remain hidden and
cause data loss later.  Unfortunately we do not yet have a
consistency checker that can root out such problems.  If you can
arrange a maintenance window to dump and load to a fresh initdb,
that would eliminate the possibility that some hidden corruption is
lurking.  If that is not possible, running VACUUM FREEZE ANALYZE
will reduce the number of things that can go wrong, without
requiring down time.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux