Re: assessing parallel-safety

On Fri, Mar 20, 2015 at 1:24 PM, Thom Brown <thom(at)linux(dot)com> wrote:
>> OK, thanks. That looks like it's probably the fault of parallel seq
>> scan patch rather than this one. It would help if you could build
>> with debug symbols so that we can see line numbers and arguments.
>
> Sure.
>
> Program received signal SIGABRT, Aborted.
> 0x00007f5a49fce1d5 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) bt
> #0 0x00007f5a49fce1d5 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1 0x00007f5a49fd1388 in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2 0x00000000007a053a in ExceptionalCondition
> (conditionName=conditionName(at)entry=0x813a4b "!(IsInParallelMode())",
> errorType=errorType(at)entry=0x7da1d6 "FailedAssertion",
> fileName=fileName(at)entry=0x81397d "parallel.c",
> lineNumber=lineNumber(at)entry=123) at assert.c:54
> #3 0x00000000004cd5ba in CreateParallelContext
> (entrypoint=entrypoint(at)entry=0x659d2c <ParallelQueryMain>,
> nworkers=nworkers(at)entry=8) at parallel.c:123
> #4 0x000000000065a1c0 in InitializeParallelWorkers (plan=0x281e6a0,
> estate=estate(at)entry=0x28b99a8, rel=rel(at)entry=0x7f594eab2370,
> inst_options_space=inst_options_space(at)entry=0x28bbfa8,
> buffer_usage_space=buffer_usage_space(at)entry=0x28bbfb0,
> responseqp=responseqp(at)entry=0x28bbf98, pcxtp=pcxtp(at)entry=0x28bbf90,
> nWorkers=8) at backendworker.c:279
> #5 0x00000000005d0e75 in InitFunnel (node=node(at)entry=0x28bbf00,
> estate=estate(at)entry=0x28b99a8, eflags=eflags(at)entry=17) at nodeFunnel.c:61
> #6 0x00000000005d1026 in ExecInitFunnel (node=0x281e738, estate=0x28b99a8,
> eflags=17) at nodeFunnel.c:121
> #7 0x00000000005c0f95 in ExecInitNode (node=0x281e738,
> estate=estate(at)entry=0x28b99a8, eflags=eflags(at)entry=17) at execProcnode.c:201
> #8 0x00000000005cd316 in ExecInitAppend (node=<optimized out>,
> estate=0x28b99a8, eflags=17) at nodeAppend.c:168
> #9 0x00000000005c0f25 in ExecInitNode (node=0x288b990,
> estate=estate(at)entry=0x28b99a8, eflags=eflags(at)entry=17) at execProcnode.c:163
> #10 0x00000000005ce849 in ExecInitAgg (node=0x288ba28, estate=0x28b99a8,
> eflags=17) at nodeAgg.c:1580
> #11 0x00000000005c10bf in ExecInitNode (node=node(at)entry=0x288ba28,
> estate=estate(at)entry=0x28b99a8, eflags=eflags(at)entry=17) at execProcnode.c:302
> #12 0x00000000005bfb35 in InitPlan (queryDesc=queryDesc(at)entry=0x28b5868,
> eflags=eflags(at)entry=17) at execMain.c:939
> #13 0x00000000005bfd49 in standard_ExecutorStart (queryDesc=0x28b5868,
> eflags=17) at execMain.c:234
> #14 0x00000000005bfd95 in ExecutorStart
> (queryDesc=queryDesc(at)entry=0x28b5868, eflags=eflags(at)entry=1) at
> execMain.c:134
> #15 0x0000000000573f21 in ExplainOnePlan
> (plannedstmt=plannedstmt(at)entry=0x28b7878, into=into(at)entry=0x0,
> es=es(at)entry=0x24cde68, queryString=queryString(at)entry=0x248a398 "EXPLAIN
> SELECT DISTINCT bid FROM pgbench_accounts;", params=params(at)entry=0x0,
> planduration=planduration(at)entry=0x7fffb64f4bf0) at explain.c:478
> #16 0x0000000000574160 in ExplainOneQuery (query=<optimized out>,
> into=into(at)entry=0x0, es=es(at)entry=0x24cde68,
> queryString=queryString(at)entry=0x248a398 "EXPLAIN SELECT DISTINCT bid FROM
> pgbench_accounts;", params=params(at)entry=0x0) at explain.c:346
> #17 0x000000000057478a in ExplainQuery (stmt=stmt(at)entry=0x248b1b0,
> queryString=queryString(at)entry=0x248a398 "EXPLAIN SELECT DISTINCT bid FROM
> pgbench_accounts;", params=params(at)entry=0x0, dest=dest(at)entry=0x24cddd0) at
> explain.c:234
> #18 0x00000000006c6419 in standard_ProcessUtility (parsetree=0x248b1b0,
> queryString=0x248a398 "EXPLAIN SELECT DISTINCT bid FROM pgbench_accounts;",
> context=PROCESS_UTILITY_TOPLEVEL, params=0x0, dest=0x24cddd0,
> completionTag=0x7fffb64f4d90 "") at utility.c:657
> #19 0x00000000006c6808 in ProcessUtility
> (parsetree=parsetree(at)entry=0x248b1b0, queryString=<optimized out>,
> context=context(at)entry=PROCESS_UTILITY_TOPLEVEL, params=<optimized out>,
> dest=dest(at)entry=0x24cddd0, completionTag=completionTag(at)entry=0x7fffb64f4d90
> "") at utility.c:333
> #20 0x00000000006c3272 in PortalRunUtility (portal=portal(at)entry=0x24f2e28,
> utilityStmt=0x248b1b0, isTopLevel=<optimized out>,
> dest=dest(at)entry=0x24cddd0, completionTag=completionTag(at)entry=0x7fffb64f4d90
> "") at pquery.c:1188
> #21 0x00000000006c4039 in FillPortalStore (portal=portal(at)entry=0x24f2e28,
> isTopLevel=isTopLevel(at)entry=1 '\001') at pquery.c:1062
> #22 0x00000000006c4a12 in PortalRun (portal=portal(at)entry=0x24f2e28,
> count=count(at)entry=9223372036854775807, isTopLevel=isTopLevel(at)entry=1 '\001',
> dest=dest(at)entry=0x248b5e8, altdest=altdest(at)entry=0x248b5e8,
> completionTag=completionTag(at)entry=0x7fffb64f4fa0 "") at pquery.c:786
> #23 0x00000000006c12c3 in exec_simple_query
> (query_string=query_string(at)entry=0x248a398 "EXPLAIN SELECT DISTINCT bid FROM
> pgbench_accounts;") at postgres.c:1107
> #24 0x00000000006c2de4 in PostgresMain (argc=<optimized out>,
> argv=argv(at)entry=0x2421c28, dbname=0x2421a90 "pgbench", username=<optimized
> out>) at postgres.c:4118
> #25 0x0000000000665c55 in BackendRun (port=port(at)entry=0x2447540) at
> postmaster.c:4148
> #26 0x00000000006675a8 in BackendStartup (port=port(at)entry=0x2447540) at
> postmaster.c:3833
> #27 0x000000000066784b in ServerLoop () at postmaster.c:1601
> #28 0x000000000066898d in PostmasterMain (argc=argc(at)entry=1,
> argv=argv(at)entry=0x2420c90) at postmaster.c:1248
> #29 0x00000000005f5a25 in main (argc=1, argv=0x2420c90) at main.c:221

That might be a different crash than the first one you showed. But it
looks like the problem here is that the parallel sequential scan patch
is calling CreateParallelContext even though this is just an EXPLAIN
and we're not actually running the query. It shouldn't do that.
(This might be an argument for postponing CreateParallelContext()
until run time, as I've suggested before.)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company