"Mikheev, Vadim" wrote:
>
> > >> 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.
Log corruption is never an unique cause of a recovery failure.
If there's a bug in redo stuff the result would also be a recovery
failure. Currently the redo stuff has to accomplish redo operations
completely. No matter how trivial the bug may be, it's always serious
unfortunately.
> 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).
>
Hmm this seems nothing worse than 7.0.
I would complain if postmaster couldn't restart due to this reason.
IIRC few ppl mind the (even system) index corruption.
> Failing to restart was bad but silent restart in the event of log
> corruption is bad too.
Agreed.
regards,
Hiroshi Inoue
