"Mikheev, Vadim" wrote:
>
> > > How about: use overwriting smgr + put old records into rollback
> > > segments - RS - (you have to keep them somewhere till TX's running
> > > anyway) + use WAL only as REDO log (RS will be used to rollback TX'
> > > changes and WAL will be used for RS/data files recovery).
> > > Something like what Oracle does.
> >
> > As long as we use no overwriting manager
> > 1) Rollback(data) isn't needed in case of a db crash.
> > 2) Rollback(data) isn't needed to cancal a transaction entirely.
>
> -1) But vacuum must read a huge amount of data to remove dirt.
> -2) But TX-s must read data they are not interested at all.
>
> > 3) We don't need to mind the transaction size so much.
>
> -3) The same with overwriting smgr and WAL used *only as REDO log*:
The larger RS becomes the longer it would take time to cancel
the transaction whereas it is executed in a momemnt under no
overwriting smgr and for example if RS exhausted all disk space
is PG really safe ? Other backends would also fail because they
couldn't write RS any mode. Many transactions would execute
UNDO operations simultaneously but there's no space to write
WALs (UNDO operations must be written to WAL also) and PG
system would abort. And could PG restart under such situations ?
Even though there's a way to recover from the situation, I
think we should avoid such dangerous situations from the
first. Basically recovery operations should never fail.
>
> > We can't use the db any longer if a REDO recovery fails now.
>
> Reset WAL and use/dump it. Annoying? Agreed. Fix bugs and/or
> use good RAM - whatever caused problem with restart.
As I already mentioned recovery operations should never fail.
>
> > Under overwriting smgr we can't use the db any longer either
> > if rollback fails.
>
> Why should it fail? Bugs? Fix them.
Rollback operations are executed much more often than
REDO recovery and it is hard to fix such bugs once PG
was released. Most people in such troubles have no
time to persue the cause. In reality I replied to the
PG restart troubles twice (with --wal-debug and pg_resetxlog
suggestions ) in Japan but got no further replies.
>
> > How could PG be not less reliable than now ?
>
> Is today' RG more reliable than Oracle, Informix, DB2?
I have never been and would never be optiomistic
about recovery. Is 7.1 more reliable than 7.0 from the
recovery POV ? I see no reason why overwriting smgr is
more relaible than no overwriting smgr as for recovery.
regards,
Hiroshi Inoue
