Re: pg_dumpall failing from possible corrupted shared memory

Richard Broersma Jr <rabroersma(at)yahoo(dot)com> 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