Re: Theory about XLogFlush startup failures

> So the failure-to-start-up problem can be blamed entirely on 7.1's
> failure to do anything with LSN fields in pg_log pages.  I was able to

No, first reported problem can be blamed on RAM failures.

> So I am still dissatisfied with doing elog(STOP) for this condition,
> as I regard it as an overly strong reaction to corrupted data;
> moreover, it does nothing to fix the problem and indeed gets in
> the way of fixing the problem.

Totally agreed but..

> I propose the attached patch.
> What do you think?
> 
...
> + 	if (XLByteLT(LogwrtResult.Flush, record))
> + 		elog(InRecovery ? NOTICE : ERROR,

I suggest also to set some flag here if InRecovery,
to elog(STOP

DATA FILE(S) CORRUPTED!
RESTORE DATA FROM BACKUP OR
RESET WAL TO DUMP/MANUALLY FIX ERRORS

- or something like that -:) - after all data buffers
flushed.

What's wrong with this? It's not Ok automatically restart
knowing about errors in data.

Vadim