Re: [GENERAL] does this look more like a possible bug or more like a possible hardware problem...? (long)
Some additional info: # select * from pg_class where relname = 'article_property_tree'; -[ RECORD 1 ]-- +--- relname| article_property_tree relnamespace | 2200 reltype| 8349772 relowner | 1000 relam | 0 relfilenode| 8349771 relpages | 4 reltuples | 299 reltoastrelid | 8349775 reltoastidxid | 0 relhasindex| t relisshared| f relkind| r relnatts | 6 relchecks | 1 reltriggers| 3 relukeys | 0 relfkeys | 0 relrefs| 0 relhasoids | t relhaspkey | t relhasrules| f relhassubclass | f relacl | {vugtf=a*r*w*d*R*x*t*/vugtf,=arwdRxt/vugtf,postgres=arwdRxt/ vugtf} -[ RECORD 2 ]-- +--- relname| article_property_tree relnamespace | 2200 reltype| 8354495 relowner | 1000 relam | 0 relfilenode| 8354494 relpages | 4 reltuples | 299 reltoastrelid | 8354498 reltoastidxid | 0 relhasindex| t relisshared| f relkind| r relnatts | 6 relchecks | 1 reltriggers| 5 relukeys | 0 relfkeys | 0 relrefs| 0 relhasoids | t relhaspkey | t relhasrules| f relhassubclass | f relacl | {vugtf=a*r*w*d*R*x*t*/vugtf,=arwdRxt/vugtf,postgres=arwdRxt/ vugtf} -- Best, Frank. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [GENERAL] does this look more like a possible bug or more like a possible hardware problem...? (long)
Frank van Vugt <[EMAIL PROTECTED]> writes: >> This is consistent with the idea that pg_attribute_relid_attnum_index is >> corrupted. I would suggest saving a copy of that file for postmortem >> analysis and then trying to REINDEX pg_attribute. > Uhm.. looking for a file named 8349771 located in the directory base/ > where nr corresponds to the proper db, using oid2name. > We seem to have a small problem : there is no such file. I'm sorry, I meant to say save a copy of pg_attribute_relid_attnum_index. The correct filename for it can be found via select relfilenode from pg_class where relname = 'pg_attribute_relid_attnum_index'; > Oid of table article_property_tree from database "megafox_trial": > - > VERY scary: more than one table with that name found!! Do you have more than one such table (presumably in different schemas)? If so this isn't scary at all. I don't believe oid2name has been fixed to be schema-aware :-( regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] does this look more like a possible bug or more like a possible hardware problem...? (long)
Frank van Vugt <[EMAIL PROTECTED]> writes: > At one point, I arrived at the following situation: > psql:/home/data/megadump.sql:5169: WARNING: specified item offset is too > large > psql:/home/data/megadump.sql:5169: PANIC: failed to add item to the page > for "pg_attribute_relid_attnum_index" > Trying the same script on a newly created database doesn't show the problem. > However, I do still have the database that came up with this message, which > is now failing a vacuum full verbose analyse with: > ERROR: catalog is missing 6 attribute(s) for relid 8349771 This is consistent with the idea that pg_attribute_relid_attnum_index is corrupted. I would suggest saving a copy of that file for postmortem analysis and then trying to REINDEX pg_attribute. (Depending on which PG version you are running, that may require running a standalone backend. See the REINDEX man page.) If REINDEX makes the problem go away, would you send me the corrupted index file off-list? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] does this look more like a possible bug or more like a possible hardware problem...? (long)
> I'm sorry, I meant to say save a copy of > pg_attribute_relid_attnum_index. The correct filename for it can be > found via > select relfilenode from pg_class where relname = > 'pg_attribute_relid_attnum_index'; Got it, made a backup of the entire database as well. Since the db wasn't filled yet, both files are fairly small when bzipped (<0.5MB and < 5MB) and both can be made available if you want. Issuing 'reindex table pg_attribute' did not solve the problem, though > > Oid of table article_property_tree from database "megafox_trial": > > - > > VERY scary: more than one table with that name found!! > > Do you have more than one such table (presumably in different schemas)? > If so this isn't scary at all. I don't believe oid2name has been fixed > to be schema-aware :-( Nope, all user-tables are in public at the moment. Also: megafox_trial=# select * from article_property_tree; ERROR: catalog is missing 6 attribute(s) for relid 8349771 -- Best, Frank. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[GENERAL] does this look more like a possible bug or more like a possible hardware problem...? (long)
Hi, I'm using a 9500 line script to create an initial database. After applying a number of changes, I was repeatedly executing this script while hunting for typos. The script itself takes care of dropping the various objects and every now and then (when delta t << autovacuum t) a manual vacuum full was performed to clean the system tables. At one point, I arrived at the following situation: db=# select version(); version PostgreSQL 7.4.1 on i586-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2.3 Message in psql terminal: psql:/home/data/megadump.sql:5169: NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "remainder_type_pkey" for table "remainder_type" psql:/home/data/megadump.sql:5169: NOTICE: CREATE TABLE / UNIQUE will create implicit index "remainder_type_abbreviation_key" for table "remainder_type" psql:/home/data/megadump.sql:5169: WARNING: specified item offset is too large psql:/home/data/megadump.sql:5169: PANIC: failed to add item to the page for "pg_attribute_relid_attnum_index" server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. psql:/home/data/megadump.sql:5169: connection to server was lost [EMAIL PROTECTED]:~> (so psql did indeed quit) The specific part in the script contains nothing strange: CREATE TABLE "remainder_type" ( "id" integer primary key check ("id" > 0), "abbreviation" varchar(20) not null unique, "descr" varchar(30) not null ); GRANT SELECT on remainder_type to PUBLIC; GRANT ALL on remainder_type to "postgres"; The server logs are mentioning this: 2004-03-09 23:11:34 [6516] LOG: statement: CREATE TABLE "remainder_type" ( "id" integer primary key check ("id" > 0), "abbreviation" varchar(20) not null unique, "descr" varchar(30) not null ); 2004-03-09 23:11:34 [6516] NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "remainder_type_pkey" for table "remainder_type" 2004-03-09 23:11:34 [6516] NOTICE: CREATE TABLE / UNIQUE will create implicit index "remainder_type_abbreviation_key" for table "remainder_type" 2004-03-09 23:11:34 [6516] WARNING: specified item offset is too large 2004-03-09 23:11:34 [6516] PANIC: failed to add item to the page for "pg_attribute_relid_attnum_index" STATEMENT: CREATE TABLE "remainder_type" ( "id" integer primary key check ("id" > 0), "abbreviation" varchar(20) not null unique, "descr" varchar(30) not null ); 2004-03-09 23:11:34 [833] LOG: server process (PID 6516) was terminated by signal 6 2004-03-09 23:11:34 [833] LOG: terminating any other active server processes 2004-03-09 23:11:34 [8074] WARNING: terminating connection because of crash of another server process DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. HINT: In a moment you should be able to reconnect to the database and repeat your command. 2004-03-09 23:11:34 [833] LOG: all server processes terminated; reinitializing 2004-03-09 23:11:34 [8075] LOG: database system was interrupted at 2004-03-09 23:11:31 CET 2004-03-09 23:11:35 [8075] LOG: checkpoint record is at 1/9FAAB5C 2004-03-09 23:11:35 [8075] LOG: redo record is at 1/9E803DC; undo record is at 0/0; shutdown FALSE 2004-03-09 23:11:35 [8075] LOG: next transaction ID: 354187; next OID: 8355508 2004-03-09 23:11:35 [8075] LOG: database system was not properly shut down; automatic recovery in progress 2004-03-09 23:11:35 [8075] LOG: redo starts at 1/9E803DC 2004-03-09 23:11:46 [8075] LOG: record with zero length at 1/B27335C 2004-03-09 23:11:46 [8075] LOG: redo done at 1/B273338 2004-03-09 23:11:55 [8075] LOG: database system is ready After this, a vacuum full verbose analyse seems to end prematurely with: INFO: vacuuming "public.stock_delivery" INFO: "stock_delivery": found 0 removable, 0 nonremovable row versions in 0 pages DETAIL: 0 dead row versions cannot be removed yet. Nonremovable row versions range from 0 to 0 bytes long. There were 0 unused item pointers. Total free space (including removable row versions) is 0 bytes. 0 pages are or will become empty, including 0 at the end of the table. 0 pages containing 0 free bytes are potential move destinations. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: index "stock_delivery_pkey" now contains 0 row versions in 1 pages DETAIL: 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.02 sec. INFO: index "stock_delivery_delivery_id_key" now contains 0 row versions in 1 pages DETAIL: 0 index pages have been deleted, 0 are currently reusable. CPU 0.00s/0.00u sec elapsed 0.00 sec. INFO: index "stock_