Обсуждение: BUG #1542: pg_dump seg fault

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'}

"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

> 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?