> As I said to Denis in the earlier thread, it would be good to try to
> track down which page is corrupted and maybe then we'd understand how
> it got that way. Since you have the database tarball, you have the
> raw material to look into it --- you'd need to rebuild Postgres with
> debug symbols enabled and trace back from the failure points to learn
> more. Are you up to that, or could you grant access to your
> machine to someone who is?
I have something to report about Denis problem but had no time so far.
> As for your immediate problem, I'd counsel reducing that elog(STOP) to
> elog(DEBUG) so that you can bring the database up, and then you can
> try to pg_dump your current data. You'll probably still want to
> re-initdb and restore once you get a consistent dump.
>
> Um, Vadim? Still of the opinion that elog(STOP) is a good idea here?
> That's two people now for whom that decision has turned localized
> corruption into complete database failure. I don't think it's a good
> tradeoff.
One is able to use pg_resetxlog so I don't see point in removing elog(STOP)
there. What do you think?
Vadim
