From: | "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | <pgsql-hackers(at)postgresql(dot)org> |
Subject: | RE: strange behaviour (bug) |
Date: | 2000-09-13 23:51:12 |
Message-ID: | 000a01c01ddd$7f3dac20$2801007e@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> -----Original Message-----
> From: Mikheev, Vadim [mailto:vmikheev(at)SECTORBASE(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2000-09-14 00:31:24 | Re: like-operator on index-scan |
Previous Message | Paul | 2000-09-13 23:32:00 | Replication of a small portion of data to another database |