> > 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*:
we are not required to keep WAL files for duration of transaction
- as soon as server knows that changes logged in some WAL file
applied to data files and RS on disk (and archived, for WAL-based
BAR) that file may be reused/removed. Old data will still occupy
space in RS but their space in data files will be available
for reuse.
> 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.
> Under overwriting smgr we can't use the db any longer either
> if rollback fails.
Why should it fail? Bugs? Fix them.
> How could PG be not less reliable than now ?
Is today' RG more reliable than Oracle, Informix, DB2?
Vadim
