> -----Original Message-----
> From: Mikheev, Vadim [mailto:vmikheev@SECTORBASE.COM]
>
> > Do we want to head for an overwriting storage manager?
> >
> > Not sure.
> >
> > Advantages: UPDATE has easy space reuse because usually done
> > in-place, no index change on UPDATE unless key is changed.
> >
> > Disadvantages: Old records have to be stored somewhere for MVCC use.
> > Could limit transaction size.
>
> Really? Why is it assumed that we *must* limit size of rollback segments?
> We can let them grow without bounds, as we do now keeping old records in
> datafiles and letting them eat all of disk space.
>
Is it proper/safe for a DBMS to allow the system eating all disk
space ? For example, could we expect to recover the database
even when no disk space available ?
1) even before WAL Is 'deleting records and vacuum' always possible ? I saw the cases that indexes grow by
vacuum.
2) under WAL(current) If DROP or VACUUM is done after a checkpoint, wouldn't REDO recovery add the pages
drop/truncatedby the DROP/VACUUM ?
3) with rollback data Shouldn't WAL log UNDO operations either ? If so, UNDO requires an extra disk space which
could be unlimitedly big.
There's another serious problem. Once UNDO is required
with a biiiig rollback data, it would take a veeery long time
to undo. It's quite different from the current behavior. Even
though people want to cancel the UNDO, there's no way
unfortunately(under an overwriting smgr).
regards,
Hiroshi Inoue
