Re: Database corruption?

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?

Well, pg_resetxlog would get around the symptom, but at the cost of
possibly losing updates that are further along in the xlog than the
update for the corrupted page. (I'm assuming that the problem here
is a page with a corrupt LSN.) I think it's better to treat flush

^^^^^^^^^^^^^^^^^^^^^^^^^^^^
On restart, entire content of all modified after last checkpoint pages
should be restored from WAL. In Denis case it looks like newly allocated
for update page was somehow corrupted before heapam.c:2235 (7.1.2 src)
and so there was no XLOG_HEAP_INIT_PAGE flag in WAL record => page
content was not initialized on restart. Denis reported system crash -
very likely due to memory problem.

request past end of log as a DEBUG or NOTICE condition and keep going.
Sure, it indicates badness somewhere, but we should try to have some
robustness in the face of that badness. I do not see any reason why
XLOG has to declare defeat and go home because of this condition.

Ok - what about setting some flag there on restart and abort restart
after all records from WAL applied? So DBA will have choice either
to run pg_resetxlog after that and try to dump data or restore from
old backup. I still object just NOTICE there - easy to miss it. And
in normal processing mode I'd leave elog(STOP) there.

Vadim
P.S. Further discussions will be in hackers-list, sorry.