Обсуждение: [7.0.2] cannot create an index ...

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

"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

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?

"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