Thread: Re: [HACKERS] A patch for FATAL 1:btree: BTP_CHAIN flag was expected
Any objection to the pacthes below? Seems they solve problems
reported by a user in Japan (both on 6.4.2 and current).
--
Tatsuo Ishii
>From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
>To: "pgsql-hackers" <pgsql-hackers@postgreSQL.org>
>Subject: [HACKERS] A patch for FATAL 1:btree: BTP_CHAIN flag was expected
>Date: Tue, 13 Apr 1999 19:00:57 +0900
>Message-ID: <000801be8594$869ad2a0$2801007e@cadzone.tpf.co.jp>
>Hello all,
>
>There exists the bug that causes elog() FATAL 1:btree:
>BTP_CHAIN flag was expected.
>The following patch would solve the bug partially.
>
>It seems that the bug is caused by _bt_split() in nbtinsert.c.
>BTP_CHAIN flags of buf/rbuf are always off immediately after
>_bt_split(),so the pages may be in inconsistent state.
>Though the flags are chagned correctly before _bt_relbuf(),
>buf/rbuf are not _bt_wrt(norel)buf()'d after the change
>(buf/rbuf are already _bt_wrtnorelbuf()'d in _bt_split() ).
>
>Comments ?
>
>Thanks.
>
>Hiroshi Inoue
>Inoue@tpf.co.jp
>
>*** backend/access/nbtree/nbtinsert.c.orig Mon Mar 29 17:00:48 1999
>--- backend/access/nbtree/nbtinsert.c Mon Apr 12 11:41:33 1999
>***************
>*** 679,686 ****
> {
> _bt_updateitem(rel, keysz, pbuf,
> stack->bts_btitem, lowLeftItem);
>! _bt_relbuf(rel, buf, BT_WRITE);
>! _bt_relbuf(rel, rbuf, BT_WRITE);
> }
> else
> {
>--- 679,686 ----
> {
> _bt_updateitem(rel, keysz, pbuf,
> stack->bts_btitem, lowLeftItem);
>! _bt_wrtbuf(rel, buf);
>! _bt_wrtbuf(rel, rbuf);
> }
> else
> {
>***************
>*** 705,712 ****
> *
> * Mmm ... I foresee problems here. - vadim 06/10/97
> */
>! _bt_relbuf(rel, buf, BT_WRITE);
>! _bt_relbuf(rel, rbuf, BT_WRITE);
>
> /*
> * A regular _bt_binsrch should find the right place
>--- 705,712 ----
> *
> * Mmm ... I foresee problems here. - vadim 06/10/97
> */
>! _bt_wrtbuf(rel, buf);
>! _bt_wrtbuf(rel, rbuf);
>
> /*
> * A regular _bt_binsrch should find the right place
>***************
>*** 731,738 ****
> }
> else
> {
>! _bt_relbuf(rel, buf, BT_WRITE);
>! _bt_relbuf(rel, rbuf, BT_WRITE);
> }
>
> newskey = _bt_mkscankey(rel, &(new_item->bti_itup));
>--- 731,738 ----
> }
> else
> {
>! _bt_wrtbuf(rel, buf);
>! _bt_wrtbuf(rel, rbuf);
> }
>
> newskey = _bt_mkscankey(rel, &(new_item->bti_itup));
>
>Hiroshi Inoue
>Inoue@tpf.co.jp
>
Tatsuo Ishii wrote: > > Any objection to the pacthes below? Seems they solve problems > reported by a user in Japan (both on 6.4.2 and current). > -- > Tatsuo Ishii > > >From: "Hiroshi Inoue" <Inoue@tpf.co.jp> > >To: "pgsql-hackers" <pgsql-hackers@postgreSQL.org> > >Subject: [HACKERS] A patch for FATAL 1:btree: BTP_CHAIN flag was expected > >Date: Tue, 13 Apr 1999 19:00:57 +0900 > >Message-ID: <000801be8594$869ad2a0$2801007e@cadzone.tpf.co.jp> > > >Hello all, > > > >There exists the bug that causes elog() FATAL 1:btree: > >BTP_CHAIN flag was expected. > >The following patch would solve the bug partially. > > > >It seems that the bug is caused by _bt_split() in nbtinsert.c. > >BTP_CHAIN flags of buf/rbuf are always off immediately after > >_bt_split(),so the pages may be in inconsistent state. > >Though the flags are chagned correctly before _bt_relbuf(), > >buf/rbuf are not _bt_wrt(norel)buf()'d after the change > >(buf/rbuf are already _bt_wrtnorelbuf()'d in _bt_split() ). > > Let me check it... I'll commit it myself... Vadim
Tatsuo Ishii wrote: > > > > >There exists the bug that causes elog() FATAL 1:btree: > >BTP_CHAIN flag was expected. > >The following patch would solve the bug partially. > > > >It seems that the bug is caused by _bt_split() in nbtinsert.c. > >BTP_CHAIN flags of buf/rbuf are always off immediately after > >_bt_split(),so the pages may be in inconsistent state. > >Though the flags are chagned correctly before _bt_relbuf(), > >buf/rbuf are not _bt_wrt(norel)buf()'d after the change > >(buf/rbuf are already _bt_wrtnorelbuf()'d in _bt_split() ). Exactly! If left/right pages would be flushed by other transaction before setting BTP_CHAIN flag then this flag would be lost! Where were my eyes! -:) Thanks, Hiroshi! Committed. All versions >= 6.1 are affected by this bug... I'll make patch for 6.4.2 in a few days if no one else... Vadim