Pivotal Knowledge Base


Planner generated plan panics in pg_detoast_datum (datum=0x0) at fmgr.c:2026


Known to affect Greenplum Database 4.X. May also affect GPDB 5.0


When running certain queries, a panic and postgres core is generated with the following stack trace:

{{Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000000379f60f6ab in raise () from /data/logs/67419/packcore-postgres.core.38304/lib64/libpthread.so.0
[Current thread is 1 (LWP 38304)]

(gdb) thread apply all bt

Thread 2 (LWP 38305):
#0  0x000000379eedf383 in poll () from /data/logs/67419/packcore-postgres.core.38304/lib64/libc.so.6
#1  0x0000000000bc2914 in rxThreadFunc (arg=<optimized out>) at ic_udpifc.c:6298
#2  0x000000379f607aa1 in start_thread () from /data/logs/67419/packcore-postgres.core.38304/lib64/libpthread.so.0
#3  0x000000379eee8bcd in clone () from /data/logs/67419/packcore-postgres.core.38304/lib64/libc.so.6

Thread 1 (LWP 38304):
#0  0x000000379f60f6ab in raise () from /data/logs/67419/packcore-postgres.core.38304/lib64/libpthread.so.0
#1  0x0000000000b00df6 in StandardHandlerForSigillSigsegvSigbus_OnMainThread (processName=<optimized out>, postgres_signal_arg=11) at elog.c:4479
#2  <signal handler called>
#3  pg_detoast_datum (datum=0x0) at fmgr.c:2026
#4  0x0000000000a66300 in numeric_eq (fcinfo=0x7ffd6b17e310) at numeric.c:992
#5  0x0000000000762392 in ExecMakeFunctionResult (fcache=<optimized out>, econtext=<optimized out>, isNull=<optimized out>, isDone=<optimized out>)
    at execQual.c:1752
#6  0x0000000000762d6d in ExecEvalOper (fcache=0x7f27289f0a18, econtext=0x7f27289f06b8, isNull=<optimized out>, isDone=0x0) at execQual.c:2225
#7  0x000000000075a2ce in ExecQual (qual=<optimized out>, econtext=0x7f27289f06b8, resultForNull=<optimized out>) at execQual.c:5341
#8  0x0000000000764c77 in ExecScan (accessMtd=<optimized out>, node=<optimized out>) at execScan.c:158
#9  ExecTableScanRelation (scanState=0x7f27289f0258) at execScan.c:434
#10 0x000000000079e1b3 in ExecTableScan (node=0x7f27289f0258) at nodeTableScan.c:42
#11 0x000000000075958d in ExecProcNode (node=0x7f27289f0258) at execProcnode.c:902
#12 0x000000000079a2aa in execMotionSender (node=<optimized out>) at nodeMotion.c:362
#13 ExecMotion (node=0x7f27289ef408) at nodeMotion.c:329
#14 0x0000000000759406 in ExecProcNode (node=0x7f27289ef408) at execProcnode.c:997
#15 0x000000000074ee8c in ExecutePlan (estate=0x194fa60, planstate=<optimized out>, operation=<optimized out>, numberTuples=<optimized out>,
    direction=<optimized out>, dest=<optimized out>) at execMain.c:2551
#16 0x000000000074f646 in ExecutorRun (queryDesc=<optimized out>, direction=<optimized out>, count=<optimized out>) at execMain.c:892
#17 0x00000000009a1399 in PortalRunSelect (dest=<optimized out>, count=<optimized out>, forward=<optimized out>, portal=<optimized out>) at pquery.c:1258
#18 PortalRun (portal=<optimized out>, count=0, isTopLevel=<optimized out>, dest=<optimized out>, altdest=<optimized out>, completionTag=<optimized out>)
    at pquery.c:1082
#19 0x0000000000999cac in exec_mpp_query (localSlice=<optimized out>, seqServerPort=<optimized out>, seqServerHost=<optimized out>,
    serializedSliceInfolen=<optimized out>, serializedSliceInfo=<optimized out>, serializedParamslen=<optimized out>, serializedParams=<optimized out>,
    serializedPlantreelen=<optimized out>, serializedPlantree=<optimized out>, serializedQuerytreelen=<optimized out>,
    serializedQuerytree=<optimized out>, query_string=<optimized out>) at postgres.c:1359
#20 PostgresMain (argc=<optimized out>, argv=<optimized out>, dbname=0x1775308 "edw_dev", username=<optimized out>) at postgres.c:4914
#21 0x00000000008f845e in BackendRun (port=<optimized out>) at postmaster.c:6978
#22 BackendStartup (port=<optimized out>) at postmaster.c:6673
#23 ServerLoop () at postmaster.c:2463
#24 0x00000000008fb100 in PostmasterMain (argc=15, argv=0x17064a0) at postmaster.c:1539
#25 0x00000000007fc8ef in main (argc=15, argv=0x1706430) at main.c:206



The cause of the crash seems to be because of a wrong plan. The plan generated contains an InitPlan that references a Param from the main query.

We're comparing a VAR with a PARAM, when the PARAM is not correctly set.

The following sql code seems to highlight the issue (the command completes, but produces an incorrect result):

edw_dev=# select   from t1 where  t1.a = (select count() over()  from t2  where t2.y = t1.a);
 a | b
(0 rows)

On a system where the issue is resolved, the correct result is as follows:

select  from t1 where  t1.a = (select count() over()  from t2  where t2.y = t1.a);
 a | b
 1 | a
(1 row)



Pivotal issue MPP-29093 was opened to address this issue. The issue report is marked "won't fix" for Greenplum Database 4 and 5. The issue is resolved in an upstream version of the product, and will be fixed in a future release.


Powered by Zendesk