Re: BUG #14344: string_agg(DISTINCT ..) crash - Mailing list pgsql-bugs

> lr@pcorp.us writes:
> Let me know if you need more info or if this has already been fixed.

> Hm, works OK for me:

> regression=# SELECT string_agg(DISTINCT state, ',' ORDER BY state) FROM
string_agg_crash_test;
>    string_agg
> -------------------
> HI,IL,KS,MA,MA,NY
> (1 row)

> But I see no post-rc1 fixes that look like they might explain this.

>            regards, tom lane


I was able to get it to crash under my mingw64 9.6beta4ish build too. Gdb
looks like this:

Reading symbols from
C:\ming64gcc48\projects\postgresql\rel\pg9.6w64gcc48\bin\postgres.exe...done
.
0x000000007732ae11 in ntdll!DbgBreakPoint ()
   from C:\Windows\SYSTEM32\ntdll.dll
(gdb) cont
Continuing.
[Thread 6944.0x61c exited with code 0]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 6944.0x2384]
toast_raw_datum_size (value=242751291) at tuptoaster.c:358
358     tuptoaster.c: No such file or directory.
(gdb) bt
#0  toast_raw_datum_size (value=242751291) at tuptoaster.c:358
#1  0x000000000078e616 in texteq (fcinfo=0x299e760) at varlena.c:1615
#2  0x00000000007bb045 in FunctionCall2Coll (flinfo=flinfo@entry=0x50ea400,
    collation=collation@entry=0, arg1=arg1@entry=85010827,
    arg2=<optimized out>) at fmgr.c:1319
#3  0x0000000000585548 in execTuplesMatch (slot1=slot1@entry=0x50e9e28,
    slot2=slot2@entry=0x50ea248, numCols=numCols@entry=2,
    matchColIdx=0x50ea350, eqfunctions=0x50ea3d0,
    evalContext=evalContext@entry=0x38d550) at execGrouping.c:100
#4  0x00000000005984e5 in process_ordered_aggregate_multi (
    pergroupstate=0x50e9980, pertrans=0x50e8968, aggstate=0x50aaaf0)
    at nodeAgg.c:1244
#5  finalize_aggregates (aggstate=aggstate@entry=0x50aaaf0,
    peraggs=peraggs@entry=0x50abfb0, pergroup=pergroup@entry=0x50e9980,
    currentSet=currentSet@entry=0) at nodeAgg.c:1552
#6  0x0000000000598c7a in agg_retrieve_direct (aggstate=0x50aaaf0)
    at nodeAgg.c:2157
#7  ExecAgg (node=node@entry=0x50aaaf0) at nodeAgg.c:1837
#8  0x000000000058b228 in ExecProcNode (node=node@entry=0x50aaaf0)
    at execProcnode.c:503
#9  0x00000000005871c5 in ExecutePlan (dest=0x50e5838,
    direction=<optimized out>, numberTuples=0, sendTuples=1 '\001',
    operation=CMD_SELECT, use_parallel_mode=<optimized out>,
    planstate=0x50aaaf0, estate=0x50aa9d8) at execMain.c:1567
#10 standard_ExecutorRun (queryDesc=0x5057288, direction=<optimized out>,
    count=0) at execMain.c:338
#11 0x00000000006b1fe6 in PortalRunSelect (portal=portal@entry=0x509e978,
    forward=forward@entry=1 '\001', count=0, count@entry=43643472,
    dest=dest@entry=0x0) at pquery.c:948
#12 0x00000000006b3686 in PortalRun (portal=0x299ee90,
    portal@entry=0x509e978, count=43643472, count@entry=2147483647,
    isTopLevel=isTopLevel@entry=0 '\000', dest=0x0, dest@entry=0x50e5838,
    altdest=altdest@entry=0x50e5838, completionTag=0x299f210 "",
    completionTag@entry=0x4000000007b <error: Cannot access memory at
address 0x4000000007b>) at pquery.c:789
#13 0x00000000006b0e54 in exec_simple_query (
    query_string=0x100000000000000 <error: Cannot access memory at address
0x100000000000000>) at postgres.c:1094
#14 PostgresMain (argc=<optimized out>, argv=argv@entry=0x2893e0,
    dbname=0x18001700160015 <error: Cannot access memory at address
0x18001700160015>, username=<optimized out>) at postgres.c:4074
#15 0x0000000000647aad in BackendRun (port=0x299f400) at postmaster.c:4262
#16 SubPostmasterMain (argc=argc@entry=3, argv=argv@entry=0x2f7ea0)
    at postmaster.c:4752
#17 0x0000000000803d68 in main (argc=3, argv=0x2f7ea0) at main.c:205
(gdb)


I'll compile against the latest 9.6 branch then and see if it crashes there
too.  Might be windows specific perhaps.

Thanks,
Regina