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.stehule@gmail.com>
wrote:

>
>
> 2017-10-11 10:49 GMT+02:00 Lukas Eder <lukas.eder@gmail.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@entry=0x2886f50) at
> tuplesort.c:1303
> 1303        MemoryContext oldcontext = MemoryContextSwitchTo(state->
> sortcontext);
> (gdb) bt
> #0  tuplesort_puttupleslot (state=0x0, slot=slot@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@entry=0x286dcf8,
> peragg=peragg@entry=0x286f630,
>     pergroupstate=0x286f800, resultVal=0x286f598, resultIsNull=0x286f5c9
> "") at nodeAgg.c:1562
> #3  0x0000000000624f9b in finalize_aggregates (aggstate=aggstate@entry=0x286dcf8,
> peraggs=peraggs@entry=0x286f5e8,
>     pergroup=pergroup@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@entry=0x286bad0,
> forward=forward@entry=1 '\001', count=0,
>     count@entry=9223372036854775807, dest=dest@entry=0x28678d0) at
> pquery.c:932
> #10 0x0000000000752a60 in PortalRun (portal=portal@entry=0x286bad0,
> count=count@entry=9223372036854775807,
>     isTopLevel=isTopLevel@entry=1 '\001', run_once=run_once@entry=1
> '\001', dest=dest@entry=0x28678d0,
>     altdest=altdest@entry=0x28678d0, completionTag=0x7fff09d671c0 "") at
> pquery.c:773
> #11 0x000000000074e6e8 in exec_simple_query (
>
> Regards
>
> Pavel
>
>
>
>