Re: server crash with CallStmt

2017-12-13 Thread Peter Eisentraut
On 12/13/17 04:46, Ashutosh Bapat wrote:
> I think it shouldn't reach this code. Like a normal function
> invocation, an aggregate invocation should not be allowed in a CALL
> statement. Here's patch to fix it. I thought that window function
> invocations and casts had similar problem, but they are prohibited by
> backend grammar.

Committed your fix, thanks.  I took out the hint, because calling an
aggregate function is a bit more complicated than just replacing the
CALL by SELECT.

-- 
Peter Eisentraut  http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: server crash with CallStmt

2017-12-13 Thread Ashutosh Bapat
On Wed, Dec 13, 2017 at 12:55 PM, Rushabh Lathia
 wrote:
> HI,
>
> Consider the below test:
>
> postgres@110311=#call sum(2+2);
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
>
> Call stack:
>
> (gdb) bt
> #0  0x7fef9b5851d7 in raise () from /lib64/libc.so.6
> #1  0x7fef9b5868c8 in abort () from /lib64/libc.so.6
> #2  0x009ec5b5 in ExceptionalCondition (conditionName=0xb7e12b
> "!(((bool) 0))", errorType=0xb7e04c "FailedAssertion",
> fileName=0xb7e040 "parse_agg.c", lineNumber=349) at assert.c:54
> #3  0x005dc3b6 in check_agglevels_and_constraints (pstate=0x2d1ba90,
> expr=0x2d1bd80) at parse_agg.c:349
> #4  0x005dc104 in transformAggregateCall (pstate=0x2d1ba90,
> agg=0x2d1bd80, args=0x2d1c3c0, aggorder=0x0, agg_distinct=0 '\000') at
> parse_agg.c:237
> #5  0x005f4df7 in ParseFuncOrColumn (pstate=0x2d1ba90,
> funcname=0x2d10578, fargs=0x2d1c3c0, last_srf=0x0, fn=0x2d10760, proc_call=1
> '\001',
> location=5) at parse_func.c:726
>
>
> Here it's hitting Assert() because pstate->p_expr_kind is set
> to EXPR_KIND_NONE for the CallStmt function resolution.
>

I think it shouldn't reach this code. Like a normal function
invocation, an aggregate invocation should not be allowed in a CALL
statement. Here's patch to fix it. I thought that window function
invocations and casts had similar problem, but they are prohibited by
backend grammar.

-- 
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
diff --git a/src/backend/parser/parse_func.c b/src/backend/parser/parse_func.c
index 2f20516..5ba6065 100644
--- a/src/backend/parser/parse_func.c
+++ b/src/backend/parser/parse_func.c
@@ -336,6 +336,16 @@ ParseFuncOrColumn(ParseState *pstate, List *funcname, List *fargs,
 		Form_pg_aggregate classForm;
 		int			catDirectArgs;
 
+		if (proc_call)
+			ereport(ERROR,
+	(errcode(ERRCODE_UNDEFINED_FUNCTION),
+	 errmsg("%s is not a procedure",
+			func_signature_string(funcname, nargs,
+  argnames,
+  actual_arg_types)),
+	 errhint("To call an aggregate function, use SELECT."),
+	 parser_errposition(pstate, location)));
+
 		tup = SearchSysCache1(AGGFNOID, ObjectIdGetDatum(funcid));
 		if (!HeapTupleIsValid(tup)) /* should not happen */
 			elog(ERROR, "cache lookup failed for aggregate %u", funcid);


server crash with CallStmt

2017-12-12 Thread Rushabh Lathia
HI,

Consider the below test:

postgres@110311=#call sum(2+2);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

Call stack:

(gdb) bt
#0  0x7fef9b5851d7 in raise () from /lib64/libc.so.6
#1  0x7fef9b5868c8 in abort () from /lib64/libc.so.6
#2  0x009ec5b5 in ExceptionalCondition (conditionName=0xb7e12b
"!(((bool) 0))", errorType=0xb7e04c "FailedAssertion",
fileName=0xb7e040 "parse_agg.c", lineNumber=349) at assert.c:54
#3  0x005dc3b6 in check_agglevels_and_constraints
(pstate=0x2d1ba90, expr=0x2d1bd80) at parse_agg.c:349
#4  0x005dc104 in transformAggregateCall (pstate=0x2d1ba90,
agg=0x2d1bd80, args=0x2d1c3c0, aggorder=0x0, agg_distinct=0 '\000') at
parse_agg.c:237
#5  0x005f4df7 in ParseFuncOrColumn (pstate=0x2d1ba90,
funcname=0x2d10578, fargs=0x2d1c3c0, last_srf=0x0, fn=0x2d10760,
proc_call=1 '\001',
location=5) at parse_func.c:726


Here it's hitting Assert() because pstate->p_expr_kind is set
to EXPR_KIND_NONE for the CallStmt function resolution.

Regards,


Thanks,
Rushabh Lathia
www.EnterpriseDB.com