
altho I'm still investigating, does anyone have an idea why the following
'CREATE TABLE' will cause this erro:

NOTICE:  CREATE TABLE/PRIMARY KEY will create implicit index 'playlist_info_pkey
' for table 'playlist_info'
FindExec: found "/pgsql/bin/postgres" using argv[0]
TRAP: Failed Assertion("!(metaopaque->btpo_flags & (1 << 3)):", File: "nbtpage.c
", Line: 181)

!(metaopaque->btpo_flags & (1 << 3)) (0) [Inappropriate ioctl for device]

CREATE TABLE "song_info" (
        "song_id" int4 NOT NULL,
        "song_name" character varying,
        "genre" character varying,
        "duration" character varying,
        "artist" character varying,
        "album" character varying,
        "url" character varying,
        "song_seq" int4,
        PRIMARY KEY ("song_id")
);


Marc G. Fournier                               scrappy@hub.org
Systems Administrator @ hub.org                    
scrappy@{postgresql|isc}.org                       ICQ#7615664


Mon, 9 Oct 2000 23:48:03 -0400 (EDT)
"Marc G. Fournier" <scrappy@hub.org>
[7.0.2] cannot create an index ...
"Marc G. Fournier" <scrappy@hub.org> writes:
> TRAP: Failed Assertion("!(metaopaque->btpo_flags & (1 << 3)):", File: "nbtpage.c
> ", Line: 181)

Hmm.  That suggests a clobbered index (as in, first page zeroed out).
The Assert report doesn't tell us which index.  Possibly a backtrace
of the corefile would help.

			regards, tom lane

Tue, 10 Oct 2000 00:25:02 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [7.0.2] cannot create an index ... 
On Tue, 10 Oct 2000, Tom Lane wrote:

> "Marc G. Fournier" <scrappy@hub.org> writes:
> > TRAP: Failed Assertion("!(metaopaque->btpo_flags & (1 << 3)):", File: "nbtpage.c
> > ", Line: 181)
> 
> Hmm.  That suggests a clobbered index (as in, first page zeroed out).
> The Assert report doesn't tell us which index.  Possibly a backtrace
> of the corefile would help.

I've rebuilt the whole data structure, as I fear it is a residual of the
crash we had last week, but, if it means anytyhing, we had done a 'drop
database/create database' before we tried to rebuild teh database ... is
it possible that the pg_log got corrupted and could affect this?  or maybe
template1, so that when the create database was run, it was pulling in
corrupted system tables?



Tue, 10 Oct 2000 00:32:12 -0400 (EDT)
"Marc G. Fournier" <scrappy@hub.org>
Re: [7.0.2] cannot create an index ... 
"Marc G. Fournier" <scrappy@hub.org> writes:
>> Hmm.  That suggests a clobbered index (as in, first page zeroed out).

> I've rebuilt the whole data structure, as I fear it is a residual of the
> crash we had last week, but, if it means anytyhing, we had done a 'drop
> database/create database' before we tried to rebuild teh database ... is
> it possible that the pg_log got corrupted and could affect this?  or maybe
> template1, so that when the create database was run, it was pulling in
> corrupted system tables?

pg_log has no indexes, so it couldn't provoke this.  But dropped bits in
an index in template1 could, since createdb just does 'cp -r' to
replicate template1 into a new database.

If you suspect template1 is hosed, you could try doing initdb in a
scratch directory and then do a diff of the resulting template1 against
your working copy.

			regards, tom lane

Tue, 10 Oct 2000 00:36:17 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [7.0.2] cannot create an index ... 