Alex Adriaanse <alex@xxxxxxxxxxxxxxxxxxx> writes: > ... possible that these particular addresses have shifted due to the > different environment and now point to irrelevant instructions. But in > case they haven't, here's the output I got: > (gdb) x/i 0x000000000049ea35 > 0x49ea35 <transformExpr+53>: callq 0x562c00 <check_stack_depth> > (gdb) x/i 0x000000000049ea00 > 0x49ea00 <transformExpr>: mov %rbx,0xffffffffffffffd0(%rsp) > (gdb) x/i 0x00000000005e7b13 > 0x5e7b13 <pfree+3>: mov 0xfffffffffffffff0(%rdi),%rdi Hmm, not exactly what I was expecting to see. The last one looks like someone passed garbage (maybe a NULL) to pfree; which would be a bug but it's not clear how memory pressure would result in that, and without knowing where pfree was called from we're not going to be able to get far investigating. The first two both seem like they could only be explained by running out of execution stack space. 8.1 takes the max_stack_depth setting you tell it as gospel, so a core dump right there is possible if you set max_stack_depth too large, but you didn't mention having changed it. In any case it's not clear why you'd get a transient spate of problems like that, unless the system was handlng especially (and unreasonably) complicated queries for awhile. Did you query the client about whether their workload could have been unusual during this episode? Of course this is all just speculation since we can't trust the addresses completely. regards, tom lane
