> -----Original Message-----
> From: Mikheev, Vadim [mailto:vmikheev@SECTORBASE.COM]
>
> > > > > I think you have identified a problem that needs
> > > > > a more general solution: we need to be robust in the case that
> > > > > an index entry is on disk that points to a tuple that never made
> > > > > it to disk.
> > >
> > > And this general solution is WAL.
> > >
> > Yes exactly.
> > But I've thought it's mainly for aborts in the middle of btree page
> > splitting or for system crash in which we couldn't expect synchronous
> > flushing of dirty buffers.
>
> Central idea of WAL - write (and flush) to log all changes made in data
> buffers _before_ data files will be changed. Buffer mgmr will be
> responsible for this. Changes made in table buffers will be logged before
> changes made in index ones, redo will insert un-inserted table rows and
> index rows will not point to unexistent tuples in table. Undo will erase
> all uncommitted changes (but will not shrink tables/indices).
>
Yes WAL would naturally solve a current flaw of index updation as a part
of its effect.
What I've never understood until recently is that even normal aborts(not
in the middle of b-tree splitting) and normal shutdown could cause an
inconsistency between heap and indices.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
