Re: seg fault crashed the postmaster

Gordon Shannon <gordo169(at)gmail(dot)com> writes:
> Stack trace:

> #0 0x00000031a147c15c in memcpy () from /lib64/libc.so.6
> #1 0x0000000000450cb8 in __memcpy_ichk (tuple=0x7fffb29ac900) at
> /usr/include/bits/string3.h:51
> #2 heap_copytuple (tuple=0x7fffb29ac900) at heaptuple.c:592
> #3 0x0000000000543d4c in EvalPlanQualFetchRowMarks (epqstate=0x3cd85ab8) at
> execMain.c:1794
> #4 0x00000000005440db in EvalPlanQual (estate=0x1e0db420,
> epqstate=0x3cd85ab8, relation=<value optimized out>, rti=4,
> tid=0x7fffb29aca20, priorXmax=<value optimized out>) at execMain.c:1401
> #5 0x00000000005592eb in ExecUpdate (node=0x3cd85a28) at
> nodeModifyTable.c:527
> #6 ExecModifyTable (node=0x3cd85a28) at nodeModifyTable.c:748
> #7 0x0000000000545953 in ExecProcNode (node=0x3cd85a28) at
> execProcnode.c:359
> #8 0x0000000000544881 in ExecutePlan (queryDesc=0x1e727990,
> direction=1039265768, count=0) at execMain.c:1190
> #9 standard_ExecutorRun (queryDesc=0x1e727990, direction=1039265768,
> count=0) at execMain.c:280
> #10 0x00002ab002c0f2b5 in explain_ExecutorRun (queryDesc=0x1e727990,
> direction=ForwardScanDirection, count=0) at auto_explain.c:203
> #11 0x00000000005f9c81 in ProcessQuery (plan=0x2112ad60,
> sourceText=0x1b3e59e0 "update v_messages set status = 'S', updated_on =
> now() where id in (select id from v_messages where author_id = 33138761 and
> status != 'S' limit 10000)",
> params=<value optimized out>, dest=0x2112ae40,
> completionTag=0x7fffb29ace20 "") at pquery.c:197

Hmm. This suggests that there's something wrong in the EvalPlanQual
code, which gets invoked when there are concurrent updates to the same
row (ie, the row this UPDATE is trying to change is one that was changed
by some other transaction since the query started). That stuff got
rewritten rather thoroughly for 9.0, so the idea of a new bug there
isn't exactly surprising. But it's going to be hard to find without
a test case. Can you show us the full schema for this table and all
the queries that execute against it up till the point of the failure?
(Turning on log_statement across all sessions would help collect that
info, if you don't have it already.)

regards, tom lane