Re: beta testing version

On Fri, Dec 01, 2000 at 08:10:40AM -0800, Vadim Mikheev wrote:
> 
> > ... a new backup utility 
> > could be written to make a hot backup which could be restored and 
> > then replayed using the current WAL format.  It might be easier to
> > add another log which could be replayed against the existing form
> > of backups.  That last is what I called the "update log".
> 
> Consistent read of data blocks is easier to implement, sure.
> 
> > The point is, WAL now does one job superbly: maintain a consistent
> > on-disk database image.  Asking it to do something else, such as 
> > supporting hot BAR, could interfere with it doing its main job.  
> > Of course, only the person who implements hot BAR can say.
> 
> There will be no interference because of BAR will not ask WAL to do
> anything else it does right now - redo-ing changes.

The interference I meant is that the current WAL file format is designed 
for its current job.  For BAR, you would be better-served by a more 
compact format, so you need not archive your logs so frequently.  
(The size of the WAL doesn't matter much because you can rotate them 
very quickly.)  A more compact format is also better as a basis for 
replication, to minimize network traffic.  To compress the WAL would 
hurt performance -- but adding performance was the point of the WAL.

A log encoded at a much higher semantic level could be much more 
compact, but wouldn't be useful as a WAL because it describes 
differences from a snapshot backup, not from the current table 
file contents.

Thus, I'm not saying that you can't implement both WAL and hot BAR
using the same log; rather, it's just not _obviously_ the best way to 
do it.  

Nathan Myers
ncm@zembu.com