Re: [HACKERS] A patch for FATAL 1:btree: BTP_CHAIN flag was expected - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: [HACKERS] A patch for FATAL 1:btree: BTP_CHAIN flag was expected
Date
Msg-id 199904260253.LAA11410@srapc451.sra.co.jp
Whole thread Raw
List 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@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
>



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] Functions with aggregations (i.e. group by) causes an abort
Next
From: Tatsuo Ishii
Date:
Subject: Re: [HACKERS] Cygwin32 fix for current