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