> Probably WAL would solve this phenomenon by rolling
> back the content of disc and shared buffer in reality.
> However if 7.0.x would be released we had better change 
> bufmgr IMHO.

I'm going to handle btree split but currently there is no way
to rollback it - we unlock splitted pages after parent
is locked and concurrent backend may update one/both of
siblings before we get our locks back.
We have to continue with split or could leave parent unchanged
and handle "my bits moved..." (ie continue split in another
xaction if we found no parent for a page) ... or we could hold
locks on all splitted pages till some parent updated without
split, but I wouldn't do this.

Vadim


Tue, 12 Sep 2000 16:36:23 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: strange behaviour (bug) 
> -----Original Message-----
> From: Mikheev, Vadim [mailto:vmikheev@SECTORBASE.COM]
> 
> > Probably WAL would solve this phenomenon by rolling
> > back the content of disc and shared buffer in reality.
> > However if 7.0.x would be released we had better change 
> > bufmgr IMHO.
> 
> I'm going to handle btree split but currently there is no way
> to rollback it - we unlock splitted pages after parent
> is locked and concurrent backend may update one/both of
> siblings before we get our locks back.
> We have to continue with split or could leave parent unchanged
> and handle "my bits moved..." (ie continue split in another
> xaction if we found no parent for a page) ... or we could hold
> locks on all splitted pages till some parent updated without
> split, but I wouldn't do this.
>

It seems to me that btree split operations must always be
rolled forward even in case of abort/crash. DO you have
other ideas ?

Regards.

Hiroshi Inoue

Thu, 14 Sep 2000 08:51:12 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: strange behaviour (bug) 