RE: xlog loose ends, continued

> >> What I was thinking about in that last paragraph was manual 
> >> analysis and recovery. I don't think it's a good idea for automatic
> >> system startup to skip over gaps in the log.
> 
> > But if we'll not try to read after gap then after restart 
> > system will not notice gap and valid records after it and
> > just rewrite log space with new records. Not much chance for
> > manual analysis - ppl will not report any problems.
> 
> That'll be true in any case, unless we refuse to start up at all upon
> detecting xlog corruption (which doesn't seem like the way to fly).
> Not sure what we can do about that.

What I would refuse in the event of log corruption is continuing
normal database operations. It's ok to dump such database for manual
recovery, but continuing to use it is VERY BAD THING. The fact that
users will use inconsistent DB may become big headache for us - just
imagine compains about index scans returning incorrect results
(index tuples pointing to free heap space was left and then that space
was used for tuple with different keys).

Failing to restart was bad but silent restart in the event of log
corruption is bad too. In first case we had at least chance to
discover original problem.

Vadim