Amitabh Kant <amitabhkant@xxxxxxxxx> writes:
> As for running the sql command as suggested by Tom, here is the result:
> template1=# select * from pg_class where pg_relation_filenode(oid) = 11678;
> pg_class | 11 | 83 | 0 | 10 | 0 |
> 0 | 0 | 8 | 281 | 0 | 0
> | t | f | p | r | 26 |
> 0 | t | f | f | f | f
> | 662 | {=r/pgsql} |
That's about the worst possible answer :-(. Without pg_class, you have
little hope of telling which is which among the other files; and there
would be no real commonality with the contents of pg_class from other
databases in the installation, so no way to jury-rig something. Moreover,
because pg_class is consulted *very* early in backend startup, it seems
entirely likely that the failure you're seeing is only the tip of the
iceberg; there very possibly are other files that are also missing or
badly damaged.
It's possible that a professional data recovery team could extract
something from the wreckage, but it would take a lot of time and money.
Personally I'd say it's time to go to your backups.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
