The following bug has been logged online:

Bug reference: 1542
Logged by: Andrew Slobodyanyk
Email address: slob@ukr.net
PostgreSQL version: 8.0.1
Operating system: linux 2.4.26, gcc 3.2.2
Description: pg_dump seg fault
Details:

After power failure any operation with tbl_test return "ERROR: could not
open relation 1663/17242/40429: No such file or directory". I try to get
information from other tables, but with or without (after deleting that
table) pg_dump crashes with seg. fault. Backtrace is:
pg_dump: reading rewrite rules

Program received signal SIGSEGV, Segmentation fault.
getRules (numRules=0x0) at pg_dump.c:3159
3159 ruleinfo[i].dobj.namespace =
ruleinfo[i].ruletable->dobj.namespace;

(gdb) bt
#0 getRules (numRules=0x0) at pg_dump.c:3159
#1 0x080585e9 in getSchemaData (numTablesPtr=0x0, schemaOnly=0 '\0',
dataOnly=0 '\0') at common.c:142
#2 0x0804a88e in main (argc=3, argv=0xbffffd34) at pg_dump.c:559
#3 0x40138b57 in __libc_start_main () from /lib/libc.so.6

(gdb) p i
$3 = 62

(gdb) p ruleinfo[i]
$4 = {dobj = {objType = DO_RULE, catId = {tableoid = 16410, oid = 40941},
dumpId = 1237, name = 0x80785f8 "_RETURN", namespace = 0x0,
dependencies = 0x0, nDeps = 0, allocDeps = 0}, ruletable = 0x0,
ev_type = 55 '7', is_instead = 0 '\0', separate = 8 '\b'}

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

"Andrew Slobodyanyk" <slob@ukr.net> writes:
> Description: pg_dump seg fault

> After power failure any operation with tbl_test return "ERROR: could not
> open relation 1663/17242/40429: No such file or directory". I try to get
> information from other tables, but with or without (after deleting that
> table) pg_dump crashes with seg. fault. Backtrace is:
> pg_dump: reading rewrite rules

> Program received signal SIGSEGV, Segmentation fault.
> getRules (numRules=0x0) at pg_dump.c:3159
> 3159 ruleinfo[i].dobj.namespace =
> ruleinfo[i].ruletable->dobj.namespace;

Hmmm. What did you do to "delete that table" exactly? The crash
suggests that there is a row in pg_rewrite that links to a nonexistent
row in pg_class. It'd be better if pg_dump emitted a more useful
failure message, of course, but the real question is how did your
system catalogs get into such a state ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

> Hmmm. What did you do to "delete that table" exactly? The crash
To tell the truth, I delete the table using Windows PgAdmin. I guess it has
done the same operation, hasn't it?

> suggests that there is a row in pg_rewrite that links to a nonexistent
> row in pg_class. It'd be better if pg_dump emitted a more useful
> failure message, of course,

It would be nice if pg_dump could backup the information from other tables,
not only showing failure message.

> but the real question is how did your system catalogs get into such a
state ...
I agree. I ask people at #postgres for tools to check state of the DB, if
structure is
alive or corrupt, because in other cases I could only guess that something
is wrong when pg_dump fails. Would you like me to send you a copy of data?


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq