Re: [HACKERS] AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()

2016-03-27 Thread Piotr Stefaniak 

On 2016-03-27 16:40, Tom Lane wrote:

Hm.  I would argue that it should have rejected CAST(NULL AS ANYARRAY).
That's a pseudotype and so there should never be an actual value of that
type, not even a null value.


I'm a little confused about what you mean here. I thought reject was 
exactly what's happening; normally you'd get "ERROR:  return type 
anyarray is not supported for SQL functions".


If you mean specifically to forbid CAST(NULL AS ANYARRAY) in general 
then I'd like to point out that there are columns of type anyarray, at 
least pg_catalog.pg_statistic.stavalues1 is, so the cast is not the only 
way to trigger this.




--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()

2016-03-27 Thread Tom Lane 
Piotr Stefaniak  writes:
> using sqlsmith I found a way to induce an AssertArg failure in 
> src/backend/executor/functions.c:check_sql_fn_retval() for 
> assert-enabled builds. It boils down to creating a function and calling 
> it like this:

> CREATE FUNCTION bad_argument_assert(anyarray, integer) RETURNS anyarray 
> LANGUAGE sql AS $$select $1$$;
> SELECT bad_argument_assert(CAST(NULL AS ANYARRAY), 0);

Hm.  I would argue that it should have rejected CAST(NULL AS ANYARRAY).
That's a pseudotype and so there should never be an actual value of that
type, not even a null value.

The Assert is positing that the type resolution system took care of
mapping some actual array type into ANYARRAY, but here the parser
didn't notice that it had anything to resolve, because it had an
exact match of input data type for the function.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] AssertArg failure in src/backend/executor/functions.c:check_sql_fn_retval()

2016-03-26 Thread Piotr Stefaniak 

Hi,

using sqlsmith I found a way to induce an AssertArg failure in 
src/backend/executor/functions.c:check_sql_fn_retval() for 
assert-enabled builds. It boils down to creating a function and calling 
it like this:


CREATE FUNCTION bad_argument_assert(anyarray, integer) RETURNS anyarray 
LANGUAGE sql AS $$select $1$$;

SELECT bad_argument_assert(CAST(NULL AS ANYARRAY), 0);

TRAP: BadArgument("!(!((rettype) == 2283 || (rettype) == 2277 || 
(rettype) == 2776 || (rettype) == 3500 || (rettype) == 3831))", File: 
"src/backend/executor/functions.c", Line: 1539)


Back-trace attached.

I've done a little bit of git-bisecting and this potential failure is 
there since at least February 2012.


The comment above the function definition specifically says that "we 
should never see a polymorphic pseudotype such as ANYELEMENT as rettype" 
but given that a non-assert-enabled build seems to cope with such 
pseudotypes well, I'm unsure the AssertArg is needed there at all.
#0  0x77341a98 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55
#1  0x7734369a in __GI_abort () at abort.c:89
#2  0x0094d594 in ExceptionalCondition (conditionName=0xb03c60 
"!(!((rettype) == 2283 || (rettype) == 2277 || (rettype) == 2776 || (rettype) 
== 3500 || (rettype) == 3831))", errorType=0xb03c51 "BadArgument", 
fileName=0xb03890 "src/backend/executor/functions.c", lineNumber=1539) at 
src/backend/utils/error/assert.c:54
#3  0x006840c9 in check_sql_fn_retval (func_id=65539, rettype=2277, 
queryTreeList=0xf3b460, modifyTargetList=0x7fffc676 "", junkFilter=0x0) at 
src/backend/executor/functions.c:1539
#4  0x0075735c in inline_function (funcid=65539, result_type=2277, 
result_collid=0, input_collid=0, args=0xf09dd0, funcvariadic=0 '\000', 
func_tuple=0x77f99c30, context=0x7fffd960) at 
src/backend/optimizer/util/clauses.c:4706
#5  0x00756508 in simplify_function (funcid=65539, result_type=2277, 
result_typmod=-1, result_collid=0, input_collid=0, args_p=0x7fffc838, 
funcvariadic=0 '\000', process_args=1 '\001', allow_non_const=1 '\001', 
context=0x7fffd960) at src/backend/optimizer/util/clauses.c:4187
#6  0x00753f87 in eval_const_expressions_mutator (node=0xf09960, 
context=0x7fffd960) at src/backend/optimizer/util/clauses.c:2834
#7  0x006cbb2f in expression_tree_mutator (node=0xf099b8, 
mutator=0x7539ac , context=0x7fffd960) at 
src/backend/nodes/nodeFuncs.c:2640
#8  0x00755ead in eval_const_expressions_mutator (node=0xf099b8, 
context=0x7fffd960) at src/backend/optimizer/util/clauses.c:3806
#9  0x006cbd2a in expression_tree_mutator (node=0xf09928, 
mutator=0x7539ac , context=0x7fffd960) at 
src/backend/nodes/nodeFuncs.c:2689
#10 0x00755ead in eval_const_expressions_mutator (node=0xf09928, 
context=0x7fffd960) at src/backend/optimizer/util/clauses.c:3806
#11 0x00753959 in eval_const_expressions (root=0xf09ae0, node=0xf09928) 
at src/backend/optimizer/util/clauses.c:2676
#12 0x007365f7 in preprocess_expression (root=0xf09ae0, expr=0xf09928, 
kind=1) at src/backend/optimizer/plan/planner.c:831
#13 0x00735f1c in subquery_planner (glob=0xf093a0, parse=0xf09048, 
parent_root=0x0, hasRecursion=0 '\000', tuple_fraction=0) at 
src/backend/optimizer/plan/planner.c:581
#14 0x00735688 in standard_planner (parse=0xf09048, cursorOptions=256, 
boundParams=0x0) at src/backend/optimizer/plan/planner.c:307
#15 0x007353ca in planner (parse=0xf09048, cursorOptions=256, 
boundParams=0x0) at src/backend/optimizer/plan/planner.c:177
#16 0x00800d28 in pg_plan_query (querytree=0xf09048, cursorOptions=256, 
boundParams=0x0) at src/backend/tcop/postgres.c:798
#17 0x00800ddb in pg_plan_queries (querytrees=0xf09aa8, 
cursorOptions=256, boundParams=0x0) at src/backend/tcop/postgres.c:857
#18 0x00801080 in exec_simple_query (query_string=0xf07ee8 "select 
public.bad_argument_assert(CAST(NULL AS ANYARRAY), 0);") at 
src/backend/tcop/postgres.c:1022
#19 0x00805342 in PostgresMain (argc=1, argv=0xe95e90, dbname=0xe95cf0 
"regression", username=0xe95cd0 "me") at src/backend/tcop/postgres.c:4059
#20 0x0077ed31 in BackendRun (port=0xeb6290) at 
src/backend/postmaster/postmaster.c:4258
#21 0x0077e495 in BackendStartup (port=0xeb6290) at 
src/backend/postmaster/postmaster.c:3932
#22 0x0077ac19 in ServerLoop () at 
src/backend/postmaster/postmaster.c:1690
#23 0x0077a24e in PostmasterMain (argc=3, argv=0xe94e10) at 
src/backend/postmaster/postmaster.c:1298
#24 0x006c6216 in main (argc=3, argv=0xe94e10) at 
src/backend/main/main.c:228

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers