server crash with CallStmt

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: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

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