Re: Combination of ordered-set aggregate function terminates JDBC connection on PostgreSQL 9.6.5

Just some notes, they may help find the cause:

- happens in 9.65. and in 10
- it can be seen with only rank and dense_rank, with any order by (asc,
desc, null):

select
rank(1) within group (order by a),
dense_rank(1) within group (order by a)
from (values (1)) t(a) ;

select
rank(1) within group (order by null),
dense_rank(1) within group (order by null)
from(values (1)) t(a) ;

- but it doesn't happen if (values (1)) is replaced with a single row
table.

On Wed, Oct 11, 2017 at 3:25 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:

>
>
> 2017-10-11 10:49 GMT+02:00 Lukas Eder <lukas(dot)eder(at)gmail(dot)com>:
>
>> When running the following query:
>>
>> select
>> cume_dist(1) within group (order by a desc),
>> rank(1) within group (order by a desc),
>> dense_rank(1) within group (order by a asc),
>> percent_rank(1) within group (order by a asc)
>> from (values(1)) t(a);
>>
>> My JDBC connection is immediately terminated:
>>
>> SQL Error [08006]: An I/O error occurred while sending to the backend.
>> An I/O error occurred while sending to the backend.
>> Connection reset
>>
>> The issue depends on a certain set of combinations of the above function
>> calls. Each function can be called individually without problems. Some
>> functions can be combined without problems as well.
>>
>> The issue can be reproduced in pgAdmin III and pgAdmin 4.
>>
>> I'm using PostgreSQL 9.6.5 on Windows 10 x86-64
>>
>> SELECT version();
>>
>> version |
>> ------------------------------------------------------------|
>> PostgreSQL 9.6.5, compiled by Visual C++ build 1800, 64-bit |
>>
>> Thanks,
>> Lukas
>>
>
> yes. It is PostgreSQL bug
>
> Program received signal SIGSEGV, Segmentation fault.
> tuplesort_puttupleslot (state=0x0, slot=slot(at)entry=0x2886f50) at
> tuplesort.c:1303
> 1303 MemoryContext oldcontext = MemoryContextSwitchTo(state->
> sortcontext);
> (gdb) bt
> #0 tuplesort_puttupleslot (state=0x0, slot=slot(at)entry=0x2886f50) at
> tuplesort.c:1303
> #1 0x00000000007ddca7 in hypothetical_dense_rank_final (fcinfo=<optimized
> out>) at orderedsetaggs.c:1344
> #2 0x00000000006244a5 in finalize_aggregate (aggstate=aggstate(at)entry=0x286dcf8,
> peragg=peragg(at)entry=0x286f630,
> pergroupstate=0x286f800, resultVal=0x286f598, resultIsNull=0x286f5c9
> "") at nodeAgg.c:1562
> #3 0x0000000000624f9b in finalize_aggregates (aggstate=aggstate(at)entry=0x286dcf8,
> peraggs=peraggs(at)entry=0x286f5e8,
> pergroup=pergroup(at)entry=0x286f800) at nodeAgg.c:1769
> #4 0x0000000000625c6d in agg_retrieve_direct (aggstate=0x286dcf8) at
> nodeAgg.c:2475
> #5 ExecAgg (pstate=0x286dcf8) at nodeAgg.c:2128
> #6 0x00000000006175ea in ExecProcNode (node=0x286dcf8) at
> ../../../src/include/executor/executor.h:251
> #7 ExecutePlan (execute_once=<optimized out>, dest=0x28678d0,
> direction=<optimized out>, numberTuples=0,
> sendTuples=<optimized out>, operation=CMD_SELECT,
> use_parallel_mode=<optimized out>, planstate=0x286dcf8,
> estate=0x286dae0) at execMain.c:1719
> #8 standard_ExecutorRun (queryDesc=0x27ccc60, direction=<optimized out>,
> count=0, execute_once=<optimized out>)
> at execMain.c:363
> #9 0x0000000000751435 in PortalRunSelect (portal=portal(at)entry=0x286bad0,
> forward=forward(at)entry=1 '\001', count=0,
> count(at)entry=9223372036854775807, dest=dest(at)entry=0x28678d0) at
> pquery.c:932
> #10 0x0000000000752a60 in PortalRun (portal=portal(at)entry=0x286bad0,
> count=count(at)entry=9223372036854775807,
> isTopLevel=isTopLevel(at)entry=1 '\001', run_once=run_once(at)entry=1
> '\001', dest=dest(at)entry=0x28678d0,
> altdest=altdest(at)entry=0x28678d0, completionTag=0x7fff09d671c0 "") at
> pquery.c:773
> #11 0x000000000074e6e8 in exec_simple_query (
>
> Regards
>
> Pavel
>
>
>
>