Re: [sqlsmith] Parallel worker executor crash on master

From: Andreas Seltenreich <seltenreich(at)gmx(dot)de>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, thomas(dot)munro(at)enterprisedb(dot)com
Subject: Re: [sqlsmith] Parallel worker executor crash on master
Date: 2017-12-16 09:13:32
Message-ID: 87h8srt4qr.fsf@ansel.ydns.eu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Kapila writes:

> This seems to be another symptom of the problem related to
> es_query_dsa for which Thomas has sent a patch on a different thread
> [1]. After applying that patch, I am not able to see the problem. I
> think due to the wrong usage of dsa across nodes, it can lead to
> sending some wrong values for params to workers.
>
> [1] - https://www.postgresql.org/message-id/CAEepm%3D0Mv9BigJPpribGQhnHqVGYo2%2BkmzekGUVJJc9Y_ZVaYA%40mail.gmail.com

while my posted recipe is indeed inconspicuous with the patch applied,
It seems to have made matters worse from the sqlsmith perspective:
Instead of one core dump per hour I get one per minute. Sample
backtrace below. I could not find a recipe yet to reproduce these
(beyond starting sqlsmith).

regards,
Andreas

Core was generated by `postgres: smith regression [local] SELECT '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 gather_getnext (gatherstate=0x555a5fff1350) at nodeGather.c:283
283 estate->es_query_dsa = gatherstate->pei->area;
#1 ExecGather (pstate=0x555a5fff1350) at nodeGather.c:216
#2 0x0000555a5d51a1ea in ExecProcNode (node=0x555a5fff1350) at ../../../src/include/executor/executor.h:242
#3 ExecutePlan (execute_once=<optimized out>, dest=0x555a604f78a0, direction=<optimized out>, numberTuples=1, sendTuples=<optimized out>, operation=CMD_SELECT, use_parallel_mode=<optimized out>, planstate=0x555a5fff1350, estate=0x555a5fff1138) at execMain.c:1718
#4 standard_ExecutorRun (queryDesc=0x555a604f78f8, direction=<optimized out>, count=1, execute_once=<optimized out>) at execMain.c:361
#5 0x0000555a5d5267cc in postquel_getnext (es=0x555a604f7418, es=0x555a604f7418, fcache=0x555a5fd1a658, fcache=0x555a5fd1a658) at functions.c:865
#6 fmgr_sql (fcinfo=0x555a60376470) at functions.c:1161
#7 0x0000555a5d5224f7 in ExecMakeFunctionResultSet (fcache=0x555a60376400, econtext=econtext(at)entry=0x555a60374090, argContext=0x555a5fd449d0, isNull=0x555a6037a60e "", isDone=isDone(at)entry=0x555a6037a698) at execSRF.c:604
#8 0x0000555a5d53dcbb in ExecProjectSRF (node=node(at)entry=0x555a60373f78, continuing=continuing(at)entry=0 '\000') at nodeProjectSet.c:175
#9 0x0000555a5d53ddf5 in ExecProjectSet (pstate=0x555a60373f78) at nodeProjectSet.c:105
#10 0x0000555a5d53d556 in ExecProcNode (node=0x555a60373f78) at ../../../src/include/executor/executor.h:242
#11 ExecNestLoop (pstate=0x555a60373da0) at nodeNestloop.c:109
#12 0x0000555a5d53d556 in ExecProcNode (node=0x555a60373da0) at ../../../src/include/executor/executor.h:242
#13 ExecNestLoop (pstate=0x555a60373248) at nodeNestloop.c:109
#14 0x0000555a5d536699 in ExecProcNode (node=0x555a60373248) at ../../../src/include/executor/executor.h:242
#15 ExecLimit (pstate=0x555a60372650) at nodeLimit.c:95
#16 0x0000555a5d5433eb in ExecProcNode (node=0x555a60372650) at ../../../src/include/executor/executor.h:242
#17 ExecSetParamPlan (node=<optimized out>, econtext=0x555a6045e948) at nodeSubplan.c:968
#18 0x0000555a5d513da8 in ExecEvalParamExec (state=<optimized out>, op=0x555a604619f0, econtext=<optimized out>) at execExprInterp.c:1921
#19 0x0000555a5d516b7e in ExecInterpExpr (state=0x555a604616e0, econtext=0x555a6045e948, isnull=<optimized out>) at execExprInterp.c:1038
#20 0x0000555a5d547cad in ExecEvalExprSwitchContext (isNull=0x7ffecac290ce "", econtext=0x555a6045e948, state=0x555a604616e0) at ../../../src/include/executor/executor.h:300
#21 ExecProject (projInfo=0x555a604616d8) at ../../../src/include/executor/executor.h:334
#22 ExecWindowAgg (pstate=0x555a6045e670) at nodeWindowAgg.c:1761
#23 0x0000555a5d536699 in ExecProcNode (node=0x555a6045e670) at ../../../src/include/executor/executor.h:242
#24 ExecLimit (pstate=0x555a6045df28) at nodeLimit.c:95
#25 0x0000555a5d51a1ea in ExecProcNode (node=0x555a6045df28) at ../../../src/include/executor/executor.h:242
#26 ExecutePlan (execute_once=<optimized out>, dest=0x555a604322a0, direction=<optimized out>, numberTuples=0, sendTuples=<optimized out>, operation=CMD_SELECT, use_parallel_mode=<optimized out>, planstate=0x555a6045df28, estate=0x555a5ffef128) at execMain.c:1718
#27 standard_ExecutorRun (queryDesc=0x555a5ff8e418, direction=<optimized out>, count=0, execute_once=<optimized out>) at execMain.c:361
#28 0x0000555a5d668ecc in PortalRunSelect (portal=portal(at)entry=0x555a5fbf5f00, forward=forward(at)entry=1 '\001', count=0, count(at)entry=9223372036854775807, dest=dest(at)entry=0x555a604322a0) at pquery.c:932
#29 0x0000555a5d66a4c0 in PortalRun (portal=portal(at)entry=0x555a5fbf5f00, count=count(at)entry=9223372036854775807, isTopLevel=isTopLevel(at)entry=1 '\001', run_once=run_once(at)entry=1 '\001', dest=dest(at)entry=0x555a604322a0, altdest=altdest(at)entry=0x555a604322a0, completionTag=0x7ffecac29380 "") at pquery.c:773
#30 0x0000555a5d66608b in exec_simple_query (query_string=0x555a5fb78178 "[...]") at postgres.c:1120
#31 0x0000555a5d667de1 in PostgresMain (argc=<optimized out>, argv=argv(at)entry=0x555a5fbb5710, dbname=<optimized out>, username=<optimized out>) at postgres.c:4139
#32 0x0000555a5d36af16 in BackendRun (port=0x555a5fb9d280) at postmaster.c:4412
#33 BackendStartup (port=0x555a5fb9d280) at postmaster.c:4084
#34 ServerLoop () at postmaster.c:1757
#35 0x0000555a5d5ec214 in PostmasterMain (argc=3, argv=0x555a5fb725a0) at postmaster.c:1365
#36 0x0000555a5d36c48d in main (argc=3, argv=0x555a5fb725a0) at main.c:228

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-12-16 14:31:33 Re: Backfill bgworker Extension?
Previous Message Amit Kapila 2017-12-16 07:23:06 Re: [sqlsmith] Parallel worker executor crash on master