> 1) WAL
> We have buffer manager, ok. So why not to use WAL as part of 
> it and don't log INSERT/UPDATE/DELETE xlog records but directly
> changes into buffer pages ? When someone dirties page it has to
> inform bmgr about dirty region and bmgr would formulate xlog record.
> The record could be for example fixed bitmap where each bit corresponds
> to part of page (of size pgsize/no-of-bits) which was changed. These
> changed regions follows. Multiple writes (by multiple backends) can be
> coalesced together as long as their transactions overlaps and there is
> enough memory to keep changed buffer pages in memory.
> 
> Pros: upper layers can think thet buffers are always safe/logged and
>       there is no special handling for indices; very simple/fast redo
> Cons: can't implement undo - but in non-overwriting is not needed (?)

But needed if we want to get rid of vacuum and have savepoints.

Vadim

Wed, 7 Mar 2001 19:34:03 -0800 
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: WAL & SHM principles
> > Pros: upper layers can think thet buffers are always safe/logged and
> >       there is no special handling for indices; very simple/fast redo
> > Cons: can't implement undo - but in non-overwriting is not needed (?)
> 
> But needed if we want to get rid of vacuum and have savepoints.

Hmm. How do you implement savepoints ? When there is rollback to savepoint
do you use xlog to undo all changes which the particular transaction has
done ? Hmmm it seems nice ... these resords are locked by such transaction
so that it can safely undo them :-)
Am I right ?

But how can you use xlog to get rid of vacuum ? Do you treat all delete
log records as candidates for free space ?

regards, devik


Fri, 9 Mar 2001 16:03:39 +0100 (CET)
Martin Devera <devik@cdi.cz>
RE: WAL & SHM principles