[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