server crash with CallStmt
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 0x00007fef9b5851d7 in raise () from /lib64/libc.so.6
#1 0x00007fef9b5868c8 in abort () from /lib64/libc.so.6
#2 0x00000000009ec5b5 in ExceptionalCondition (conditionName=0xb7e12b
"!(((bool) 0))", errorType=0xb7e04c "FailedAssertion",
fileName=0xb7e040 "parse_agg.c", lineNumber=349) at assert.c:54
#3 0x00000000005dc3b6 in check_agglevels_and_constraints
(pstate=0x2d1ba90, expr=0x2d1bd80) at parse_agg.c:349
#4 0x00000000005dc104 in transformAggregateCall (pstate=0x2d1ba90,
agg=0x2d1bd80, args=0x2d1c3c0, aggorder=0x0, agg_distinct=0 '\000') at
parse_agg.c:237
#5 0x00000000005f4df7 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
On Wed, Dec 13, 2017 at 12:55 PM, Rushabh Lathia
<rushabh.lathia@gmail.com> 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 0x00007fef9b5851d7 in raise () from /lib64/libc.so.6
#1 0x00007fef9b5868c8 in abort () from /lib64/libc.so.6
#2 0x00000000009ec5b5 in ExceptionalCondition (conditionName=0xb7e12b
"!(((bool) 0))", errorType=0xb7e04c "FailedAssertion",
fileName=0xb7e040 "parse_agg.c", lineNumber=349) at assert.c:54
#3 0x00000000005dc3b6 in check_agglevels_and_constraints (pstate=0x2d1ba90,
expr=0x2d1bd80) at parse_agg.c:349
#4 0x00000000005dc104 in transformAggregateCall (pstate=0x2d1ba90,
agg=0x2d1bd80, args=0x2d1c3c0, aggorder=0x0, agg_distinct=0 '\000') at
parse_agg.c:237
#5 0x00000000005f4df7 in ParseFuncOrColumn (pstate=0x2d1ba90,
funcname=0x2d10578, fargs=0x2d1c3c0, last_srf=0x0, fn=0x2d10760, proc_call=1
'\001',
location=5) at parse_func.c:726Here 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
Attachments:
call_agg_fix.patchtext/x-patch; charset=US-ASCII; name=call_agg_fix.patchDownload
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);
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