Re: BUG #14344: string_agg(DISTINCT ..) crash

> lr(at)pcorp(dot)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(at)entry=0x50ea400,
collation=collation(at)entry=0, arg1=arg1(at)entry=85010827,
arg2=<optimized out>) at fmgr.c:1319
#3 0x0000000000585548 in execTuplesMatch (slot1=slot1(at)entry=0x50e9e28,
slot2=slot2(at)entry=0x50ea248, numCols=numCols(at)entry=2,
matchColIdx=0x50ea350, eqfunctions=0x50ea3d0,
evalContext=evalContext(at)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(at)entry=0x50aaaf0,
peraggs=peraggs(at)entry=0x50abfb0, pergroup=pergroup(at)entry=0x50e9980,
currentSet=currentSet(at)entry=0) at nodeAgg.c:1552
#6 0x0000000000598c7a in agg_retrieve_direct (aggstate=0x50aaaf0)
at nodeAgg.c:2157
#7 ExecAgg (node=node(at)entry=0x50aaaf0) at nodeAgg.c:1837
#8 0x000000000058b228 in ExecProcNode (node=node(at)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(at)entry=0x509e978,
forward=forward(at)entry=1 '\001', count=0, count(at)entry=43643472,
dest=dest(at)entry=0x0) at pquery.c:948
#12 0x00000000006b3686 in PortalRun (portal=0x299ee90,
portal(at)entry=0x509e978, count=43643472, count(at)entry=2147483647,
isTopLevel=isTopLevel(at)entry=0 '\000', dest=0x0, dest(at)entry=0x50e5838,
altdest=altdest(at)entry=0x50e5838, completionTag=0x299f210 "",
completionTag(at)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(at)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(at)entry=3, argv=argv(at)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