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?