> > 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 ?

Yes, it should, but hard to implement, especially for abort case.
So, for the moment, I would proceed with handling "my bits moved...":
no reason to elog(FATAL) here - we can try to insert missed pointers
into parent page(s). WAL will guarantee that btitems moved to right
sibling will not be lost (level consistency), and missing some pointers
in parent level is acceptable - scans will work.

Vadim

Thu, 14 Sep 2000 10:17:56 -0700
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: strange behaviour (bug) 
> -----Original Message-----
> From: Mikheev, Vadim [mailto:vmikheev@SECTORBASE.COM]
> 
> > > 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 ?
> 
> Yes, it should, but hard to implement, especially for abort case.
> So, for the moment, I would proceed with handling "my bits moved...":
> no reason to elog(FATAL) here - we can try to insert missed pointers
> into parent page(s). WAL will guarantee that btitems moved to right
> sibling will not be lost (level consistency), and missing some pointers
> in parent level is acceptable - scans will work.
>

I looked into your XLOG stuff a little.
It seems that XLogFileOpen() isn't implemented yet.
Would/should XLogFIleOpen() guarantee to open a Relation
properly at any time ?

Regards.

Hiroshi Inoue

Fri, 15 Sep 2000 08:38:39 +0900
"Hiroshi Inoue" <Inoue@tpf.co.jp>
RE: strange behaviour (bug) 