Il 03-11-2016 00:21 Jim Nasby ha scritto:
On 11/2/16 2:02 PM, Gionatan Danti wrote: That means at least some of the Postgres files have been damaged (possibly due to the failing disk). Postgres will complain when it sees internal data structures that don't make sense, but it has no way to know if any of the user data has been screwed up.
I understand that (unfortunately) user data *will* be corrupted/lost. However, having no backup, I think the customer *must* accept that...
I wouldn't trust the existing cluster that far. Since it sounds like you have no better options, you could use zero_damaged_pages to allow a pg_dumpall to complete, but you're going to end up with missing data. So what I'd suggest would be: stop Postgres make a copy of the cluster start with zero_damaged_pages pg_dumpall stop and remove the cluster (make sure you've got that backup) create a new cluster and load the dump
The whole dump/restore approach surely is the most sensible one. However, I am concerned that if the dump have some undetected problems leading to a failed restore, I had to recover from the raw files (which I would like to avoid). Moreover, the expected remaining lifetime of such a database is 2/3 months only, as a new production system should be installed shortly. This is why I would prefer to use vacuum/reindex and avoid a full dump/restore.
Thank you very much Jim. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti@xxxxxxxxxx - info@xxxxxxxxxx GPG public key ID: FF5F32A8 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
