"Heinemann, Manfred (IMS)" <HeinemannM@imsweb.com> writes:
> Here is what I get for the stack trace, is it more helpful?
> Program received signal SIGSEGV, Segmentation fault.
> 0x000000000084dcb0 in pglz_decompress ()
> #0 0x000000000084dcb0 in pglz_decompress ()
> #1 0x00000000004b8d2f in toast_decompress_datum ()
> #2 0x0000000000793ce0 in numeric_eq ()
> #3 0x00000000005e68eb in ExecInterpExpr ()
> #4 0x00000000005ef589 in ExecScan ()
> #5 0x0000000000608784 in ExecNestLoop ()
> #6 0x00000000005fc6b5 in ExecGather ()
> #7 0x00000000005feb35 in ExecHashJoin ()
> #8 0x00000000006086d4 in ExecNestLoop ()
> #9 0x00000000005e9b02 in standard_ExecutorRun ()
> #10 0x000000000071305b in PortalRunSelect ()
> #11 0x00000000007142d1 in PortalRun ()
> #12 0x000000000071038b in exec_simple_query ()
> #13 0x0000000000711589 in PostgresMain ()
> #14 0x0000000000476399 in ServerLoop ()
> #15 0x00000000006a9acc in PostmasterMain ()
> #16 0x000000000062b58c in main ()
Hmm. So (1) apparently we have some corrupt data in a numeric column,
and (2) it looks like the crash is happening in a parallel leader
process, not a worker process, which makes it pretty mystifying why
it's connected to parallelism at all.
But we're not going to be able to get far with that amount of info.
Is there any chance of extracting a self-contained test case?
regards, tom lane
