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

Pavel Stehule <pavel.stehule@gmail.com>

From: Pavel Stehule <pavel.stehule@gmail.com>
To: Lukas Eder <lukas.eder@gmail.com>
Cc: "pgsql-bugs@postgresql.org" <pgsql-bugs@postgresql.org>
Date: 2017-10-11T14:25:20Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Treat aggregate direct arguments as per-agg data not per-trans data.

  2. Allow the built-in ordered-set aggregates to share transition state.

  3. Fix AggGetAggref() so it won't lie to aggregate final functions.

  4. Prevent sharing transition states between ordered-set aggregates.

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