Re: [HACKERS] A patch for FATAL 1:btree: BTP_CHAIN flag was expected

From: Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
Cc: "pgsql-hackers" <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] A patch for FATAL 1:btree: BTP_CHAIN flag was expected
Date: 1999-04-26 02:53:04
Message-ID: 199904260253.LAA11410@srapc451.sra.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)tpf(dot)co(dot)jp>
>To: "pgsql-hackers" <pgsql-hackers(at)postgreSQL(dot)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(at)cadzone(dot)tpf(dot)co(dot)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(at)tpf(dot)co(dot)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(at)tpf(dot)co(dot)jp
>

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 1999-04-26 04:47:34 Re: [HACKERS] Cygwin32 fix for current
Previous Message Tom Lane 1999-04-26 00:46:56 Re: [HACKERS] Functions with aggregations (i.e. group by) causes an abort