Richard Broersma Jr <rabroersma@xxxxxxxxx> writes: > You'll have to forgive me. I've never used gdb before, I am not sure I > am executing gdb with the correct syntax. However, I was able to > produce a core file. Here is the syntax that I used that produced the > most output - althought it doesn't look like what you would want. No, this is good --- it'd be better with debug symbols, but there's enough here to give us an idea where the problem is: > gdb> stack > #0 0xb7cc871b in strtouq () from /lib/libc.so.6 > #1 0xb7cc847f in __strtol_internal () from /lib/libc.so.6 > #2 0x08178404 in nodeToString () > #3 0x081794fa in parseNodeString () > #4 0x0817b2ff in nodeRead () > #5 0x0817b16f in nodeRead () > #6 0x081780ed in nodeToString () > #7 0x081795fa in parseNodeString () > #8 0x0817b2ff in nodeRead () > #9 0x0817b16f in nodeRead () > #10 0x0817b839 in stringToNode () > #11 0x082264fb in pg_get_constraintdef () > #12 0x0822667e in pg_get_indexdef () > #13 0x08144ff5 in ExecProject () > #14 0x081449ef in ExecProject () > #15 0x08153aa5 in ExecMergeJoin () What this looks like is that there's a mangled expression string in the catalog entry for either a check constraint or an expression index. The backend is dying while trying to decompile the expression for pg_dump. What I suggest doing is turning on log_statement = all and running pg_dump, so that you can see the query it's dying on. That would give you enough info to look into the catalog entry for the constraint or index at hand. Worst-case, you can probably fix things by dropping and recreating the constraint or index ... but before you do that, I'd urge you to try to get as much info as you can about the nature of the catalog corruption. If there's a bug here, as opposed to random cosmic-ray damage, we can't fix it without more info. regards, tom lane
