[
https://issues.apache.org/jira/browse/HAWQ-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15097749#comment-15097749
]
Ruilong Huo commented on HAWQ-328:
----------------------------------
Linking to HAWQ-133 since HAWQ-328 is a duplication of HAWQ-133. The root cause
is query resource in plan statement is not properly assigned.
{noformat}
(gdb) bt
#0 0x00000038cc20f5db in raise () from /lib64/libpthread.so.0
#1 0x00000000009e583b in SafeHandlerForSegvBusIll (processName=0xd55693
"Master process", postgres_signal_arg=11) at elog.c:4497
#2 0x00000000009e5a68 in StandardHandlerForSigillSigsegvSigbus_OnMainThread
(processName=0xd55693 "Master process", postgres_signal_arg=11) at elog.c:4575
#3 0x00000000008f8a3e in CdbProgramErrorHandler (postgres_signal_arg=11) at
postgres.c:3405
#4 <signal handler called>
#5 0x0000000000b838b7 in list_length (l=0x7f7f7f7f7f7f7f7f) at
../../../src/include/nodes/pg_list.h:99
#6 0x0000000000b841c4 in initialize_dispatch_data (resource=0x265d1f8,
dispatch_to_all_cached_executors=0 '\000') at dispatcher.c:460
#7 0x000000000071a4df in ExecutorStart (queryDesc=0x2717a78, eflags=0) at
execMain.c:924
#8 0x0000000000786103 in _SPI_pquery (queryDesc=0x2717a78, fire_triggers=1
'\001', tcount=1) at spi.c:2167
#9 0x0000000000785b82 in _SPI_execute_plan (plan=0x2859618, Values=0x2645b58,
Nulls=0x2646308 "~\177\177\177\177\177\177\177PPd\002", snapshot=0x0,
crosscheck_snapshot=0x0, read_only=0 '\000', fire_triggers=1 '\001', tcount=1)
at spi.c:1924
#10 0x0000000000782d69 in SPI_execute_plan (plan=0x2859618, Values=0x2645b58,
Nulls=0x2646308 "~\177\177\177\177\177\177\177PPd\002", read_only=0 '\000',
tcount=1) at spi.c:491
#11 0x00007f7b26e2947f in exec_stmt_execsql (estate=0x7fff3df05140,
stmt=0x264a140) at pl_exec.c:2488
#12 0x00007f7b26e2707d in exec_stmt (estate=0x7fff3df05140, stmt=0x264a140) at
pl_exec.c:1255
#13 0x00007f7b26e26d5f in exec_stmts (estate=0x7fff3df05140, stmts=0x2649f98)
at pl_exec.c:1170
#14 0x00007f7b26e27ac4 in exec_stmt_fori (estate=0x7fff3df05140,
stmt=0x2649798) at pl_exec.c:1609
#15 0x00007f7b26e26fdb in exec_stmt (estate=0x7fff3df05140, stmt=0x2649798) at
pl_exec.c:1231
#16 0x00007f7b26e26d5f in exec_stmts (estate=0x7fff3df05140, stmts=0x26494e8)
at pl_exec.c:1170
#17 0x00007f7b26e26b41 in exec_stmt_block (estate=0x7fff3df05140,
block=0x264a5f0) at pl_exec.c:1113
#18 0x00007f7b26e24f57 in plpgsql_exec_function (func=0x24ea120,
fcinfo=0x7fff3df053e0) at pl_exec.c:291
#19 0x00007f7b26e1ff2e in plpgsql_call_handler (fcinfo=0x7fff3df053e0) at
pl_handler.c:95
#20 0x000000000072a24b in ExecMakeFunctionResult (fcache=0x26e87c0,
econtext=0x26e8590, isNull=0x26e93f0
"\177~\177\177\177\177\177\177\030\022l\002", isDone=0x26e94e8) at
execQual.c:1749
#21 0x000000000072af19 in ExecEvalFunc (fcache=0x26e87c0, econtext=0x26e8590,
isNull=0x26e93f0 "\177~\177\177\177\177\177\177\030\022l\002",
isDone=0x26e94e8) at execQual.c:2197
#22 0x0000000000732a75 in ExecTargetList (targetlist=0x26e9040,
econtext=0x26e8590, values=0x26e93b0, isnull=0x26e93f0
"\177~\177\177\177\177\177\177\030\022l\002", itemIsDone=0x26e94e8,
isDone=0x7fff3df05934) at execQual.c:5426
#23 0x0000000000732f1c in ExecProject (projInfo=0x26e9430,
isDone=0x7fff3df05934) at execQual.c:5612
#24 0x0000000000764460 in ExecResult (node=0x26c22e0) at nodeResult.c:220
#25 0x0000000000725c47 in ExecProcNode (node=0x26c22e0) at execProcnode.c:887
#26 0x000000000076c5cc in ExecSetParamPlan (node=0x26c1f70, econtext=0x26c1290,
gbl_queryDesc=0x0) at nodeSubplan.c:1143
#27 0x0000000000728e6f in ExecEvalParam (exprstate=0x26c14c0,
econtext=0x26c1290, isNull=0x26c1e38
"\177~\177\177\177\177\177\177\030\022l\002", isDone=0x26c1f30) at
execQual.c:972
#28 0x0000000000732a75 in ExecTargetList (targetlist=0x26c1560,
econtext=0x26c1290, values=0x26c1df8, isnull=0x26c1e38
"\177~\177\177\177\177\177\177\030\022l\002", itemIsDone=0x26c1f30,
isDone=0x7fff3df05d44) at execQual.c:5426
#29 0x0000000000732f1c in ExecProject (projInfo=0x26c1e78,
isDone=0x7fff3df05d44) at execQual.c:5612
#30 0x0000000000764460 in ExecResult (node=0x26c0de0) at nodeResult.c:220
#31 0x0000000000725c47 in ExecProcNode (node=0x26c0de0) at execProcnode.c:887
#32 0x000000000071ed2c in ExecutePlan (estate=0x26c07e8, planstate=0x26c0de0,
operation=CMD_SELECT, numberTuples=0, direction=ForwardScanDirection,
dest=0x2623238) at execMain.c:3202
#33 0x000000000071adf3 in ExecutorRun (queryDesc=0x26bf4b0,
direction=ForwardScanDirection, count=0) at execMain.c:1198
#34 0x00000000009000b8 in PortalRunSelect (portal=0x2628808, forward=1 '\001',
count=0, dest=0x2623238) at pquery.c:1631
#35 0x00000000008ffc95 in PortalRun (portal=0x2628808,
count=9223372036854775807, isTopLevel=1 '\001', dest=0x2623238,
altdest=0x2623238, completionTag=0x7fff3df063a0 "") at pquery.c:1453
#36 0x00000000008f5d5f in exec_simple_query (query_string=0x258e238 "select
funcloop();", seqServerHost=0x0, seqServerPort=-1) at postgres.c:1723
#37 0x00000000008fa99f in PostgresMain (argc=4, argv=0x24d92b0,
username=0x24d97e0 "gpadmin") at postgres.c:4693
#38 0x00000000008a0e62 in BackendRun (port=0x2487c80) at postmaster.c:5857
#39 0x00000000008a02ec in BackendStartup (port=0x2487c80) at postmaster.c:5450
#40 0x000000000089a319 in ServerLoop () at postmaster.c:2129
#41 0x00000000008993dc in PostmasterMain (argc=9, argv=0x249e940) at
postmaster.c:1421
#42 0x00000000007b2d2e in main (argc=9, argv=0x249e940) at main.c:226
{noformat}
> plsql loop three times exit abnormality
> ---------------------------------------
>
> Key: HAWQ-328
> URL: https://issues.apache.org/jira/browse/HAWQ-328
> Project: Apache HAWQ
> Issue Type: Bug
> Components: Catalog
> Reporter: longgeligelong
> Assignee: Ruilong Huo
> Priority: Blocker
>
> plsql of hawq loop three times exit abnormality.
> Add print in code, Then I found when program looped third time, before
> running line 824 in src/backend/executor/execMain.c, the value of
> queryDesc->plannedstmt->resource->type is 1050. After running this line the
> value became a random number. But after running this line in the tirst two
> loop, the value is still 1050. Because queryDesc is not a actual parameter
> of prepareDispatchedCatalogRelation in line 824, I cannot continue to keep
> track of code.
> stdour and stderr as below :
> psql:test_plsql_loop.sql:66: NOTICE: for loop: quantity here is 1
> psql:test_plsql_loop.sql:66: NOTICE: FOR LOOP: ROW HERE IS (14929)
> psql:test_plsql_loop.sql:66: NOTICE: for loop: quantity here is 2
> psql:test_plsql_loop.sql:66: NOTICE: FOR LOOP: ROW HERE is (14929)
> psql:test_plsql_loop.sql:66: NOTICE: for loop: quantity here is 3
> psql:test_plsql_loop.sql:66: ERROR: could not serialize unrecognized node
> type: 38814640 (outfast.c:4742)
> CONTEXT: SQL statement "SELECT COUNT(1) FROM oiq_t_2"
> PL/pgSQL function "func2" line 11 at SQL statement
> plsql code as below:
> CREATE OR REPLACE FUNCTION funcloop() RETURNS text AS $func$
> DECLARE
> rowvar RECORD;
> BEGIN
> FOR i IN 1..10 LOOP
> RAISE NOTICE 'loop: quantity here is %', i;
> SELECT COUNT(1) INTO rowvar FROM oiq_t_2;
> RAISE NOTICE 'FOR LOOP: ROW HERE IS %', rowvar;
> END LOOP;
> return rowvar;
> END;
> $func$ LANGUAGE plpgsql;
> select funcloop();
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
