RE: strange behaviour (bug) - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject RE: strange behaviour (bug)
Date
Msg-id 000a01c01ddd$7f3dac20$2801007e@tpf.co.jp
Whole thread Raw
In response to RE: strange behaviour (bug)  ("Mikheev, Vadim" <vmikheev@SECTORBASE.COM>)
List pgsql-hackers
> -----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


pgsql-hackers by date:

Previous
From: Paul
Date:
Subject: Replication of a small portion of data to another database
Next
From: Tom Lane
Date:
Subject: Re: like-operator on index-scan