Thread: FWD: bug report: index is not a btree

The following bug has been logged online:

Bug reference:      1802
Logged by:          Jenny Wang
Email address:      y6108@vip.sina.com
PostgreSQL version: 7.3.10
Operating system:   RedHat 8
Description:        index is not a btree
Details:

1 $ cd <prefix>
  $ cd bin

2 $ ./postmaster -D data &
  $ ./psql TEST
  TEST=#create table a(col1 int primary key);

3 $ kill -9 <postmaster pid>

4 $ ./postmaster -D data &
  $ ./psql TEST
  TEST=#insert into a values(1);

  ERROR:  Index a_pkey is not a btree

  the file of a_pkey has size 8k, and is all zero.

On Wed, Aug 03, 2005 at 09:46:23AM -0000, Greg Sabino Mullane wrote:
>
> 2 $ ./postmaster -D data &
>   $ ./psql TEST
>   TEST=#create table a(col1 int primary key);
>
> 3 $ kill -9 <postmaster pid>
>
> 4 $ ./postmaster -D data &
>   $ ./psql TEST
>   TEST=#insert into a values(1);
>
>   ERROR:  Index a_pkey is not a btree
>
>   the file of a_pkey has size 8k, and is all zero.

I can duplicate this in 7.3.10, but only if the postmaster does a
redo when it restarts.  If I do a checkpoint before killing the
postmaster then the insert succeeds.

I couldn't duplicate this behavior in 7.4.8, 8.0.3, or HEAD.  The
7.4 Release Notes have an item about making B-tree indexes fully
WAL-safe, so I wonder if that fixes the problem.

--
Michael Fuhr
http://www.fuhr.org/~mfuhr/

Michael Fuhr <mike@fuhr.org> writes:
> I can duplicate this in 7.3.10, but only if the postmaster does a
> redo when it restarts.  If I do a checkpoint before killing the
> postmaster then the insert succeeds.
> I couldn't duplicate this behavior in 7.4.8, 8.0.3, or HEAD.  The
> 7.4 Release Notes have an item about making B-tree indexes fully
> WAL-safe, so I wonder if that fixes the problem.

Yeah.  Before 7.4 there was no WAL record emitted for the act of
initializing the btree metapage, so this behavior is pretty much
exactly what you'd expect.  It's possible that we could backport
that single change, but if memory serves there were a number of
other ways in which btree index build violated the WAL principle,
so I'm not sure there's much point.  You more or less had to
checkpoint to be sure the new index is fully down to disk.

            regards, tom lane