Обсуждение: 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