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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
