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
