11beta crash/assert caused by parameter type changes

From: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
To: pgsql-hackers(at)postgresql(dot)org
Subject: 11beta crash/assert caused by parameter type changes
Date: 2018-07-24 20:50:40
Message-ID: 87wotkfju1.fsf@news-spur.riddles.org.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

This crashes for me with an assert failure on latest 11-stable (and
12devel):

create or replace function foo(text)
returns text language plpgsql
as $$
declare
r record;
t text;
begin
execute $1 into r;
select pg_typeof(r.a) into t; -- dies on this one
return format('type %s value %s', t, r.a::text);
end;
$$;

contrib_regression=# select foo('select 1 as a');
foo
----------------------
type integer value 1
(1 row)

contrib_regression=# select foo('select now() as a');
server closed the connection unexpectedly

The assert is in eval_const_expressions_mutator:

2586 Assert(prm->ptype == param->paramtype);

In 10.x I don't seem to get the assert but it does give a runtime error
from the executor ("type ... does not match that when preparing the plan").

Haven't had time yet to poke at what's changed in detail.

Here's the backtrace:

#3 0x0000000000b42d34 in ExceptionalCondition (conditionName=0xd2765c "!(prm->ptype == param->paramtype)",
errorType=0xbc0d4d "FailedAssertion", fileName=0xd27971 "clauses.c", lineNumber=2586) at assert.c:54
#4 0x0000000000882a0e in eval_const_expressions_mutator (node=0x80bea4438, context=0x7fffffffcc18) at clauses.c:2586
#5 0x00000000007d5311 in expression_tree_mutator (node=0x80bea43d8, mutator=0x8828a0 <eval_const_expressions_mutator>,
context=0x7fffffffcc18) at nodeFuncs.c:2914
#6 0x00000000008868b3 in simplify_function (funcid=1619, result_type=2206, result_typmod=-1, result_collid=0, input_collid=0,
args_p=0x7fffffffb4d0, funcvariadic=false, process_args=true, allow_non_const=true, context=0x7fffffffcc18) at clauses.c:4053
#7 0x0000000000882d99 in eval_const_expressions_mutator (node=0x80bea4380, context=0x7fffffffcc18) at clauses.c:2674
#8 0x00000000007d50fa in expression_tree_mutator (node=0x80bea4328, mutator=0x8828a0 <eval_const_expressions_mutator>,
context=0x7fffffffcc18) at nodeFuncs.c:2865
#9 0x000000000088516a in eval_const_expressions_mutator (node=0x80bea4328, context=0x7fffffffcc18) at clauses.c:3669
#10 0x00000000007d5311 in expression_tree_mutator (node=0x80bea42c8, mutator=0x8828a0 <eval_const_expressions_mutator>,
context=0x7fffffffcc18) at nodeFuncs.c:2914
#11 0x000000000088516a in eval_const_expressions_mutator (node=0x80bea42c8, context=0x7fffffffcc18) at clauses.c:3669
#12 0x0000000000882891 in eval_const_expressions (root=0x80bea4530, node=0x80bea42c8) at clauses.c:2472
#13 0x000000000085ed22 in preprocess_expression (root=0x80bea4530, expr=0x80bea42c8, kind=1) at planner.c:1041
#14 0x000000000085df1a in subquery_planner (glob=0x80bea4498, parse=0x80bea4178, parent_root=0x0, hasRecursion=false,
tuple_fraction=0) at planner.c:732
#15 0x000000000085d34d in standard_planner (parse=0x80bea4178, cursorOptions=256, boundParams=0x802ffa118) at planner.c:405
#16 0x000000000085d0c0 in planner (parse=0x80bea4178, cursorOptions=256, boundParams=0x802ffa118) at planner.c:263
#17 0x0000000000987270 in pg_plan_query (querytree=0x80bea4178, cursorOptions=256, boundParams=0x802ffa118) at postgres.c:809
#18 0x00000000009873d1 in pg_plan_queries (querytrees=0x80bea4118, cursorOptions=256, boundParams=0x802ffa118) at postgres.c:875
#19 0x0000000000b28d3e in BuildCachedPlan (plansource=0x80bea3118, qlist=0x80bea4118, boundParams=0x802ffa118, queryEnv=0x0)
at plancache.c:938
#20 0x0000000000b28231 in GetCachedPlan (plansource=0x80bea3118, boundParams=0x802ffa118, useResOwner=true, queryEnv=0x0)
at plancache.c:1213
#21 0x00000000007a767b in _SPI_execute_plan (plan=0x80becc118, paramLI=0x802ffa118, snapshot=0x0, crosscheck_snapshot=0x0,
read_only=false, fire_triggers=true, tcount=1) at spi.c:2127
#22 0x00000000007a81cd in SPI_execute_plan_with_paramlist (plan=0x80becc118, params=0x802ffa118, read_only=false, tcount=1)
at spi.c:486
#23 0x000000080c023bfc in exec_stmt_execsql (estate=0x7fffffffd548, stmt=0x80bead5a0) at pl_exec.c:4084
[etc]

--
Andrew (irc:RhodiumToad)

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2018-07-24 20:57:09 Re: [HACKERS] Optional message to user when terminating/cancelling backend
Previous Message Daniel Gustafsson 2018-07-24 20:46:41 Re: [HACKERS] Optional message to user when terminating/cancelling backend