On 21.12.2014 20:19, Tomas Vondra wrote: > > However, I got a segfault on the very first query I tried :-( > > create table test_hash_agg as select i AS a, i AS b, i AS c, i AS d > from generate_series(1,10000000) s(i); > > analyze test_hash_agg; > > select a, count(*) from test_hash_agg where a < 100000 group by a; > > With a fresh cluster (default config), I get this: > > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: Failed. > > The backtrace looks like this (full attached): > > Program received signal SIGSEGV, Segmentation fault. > advance_transition_function (aggstate=aggstate@entry=0x2b5c5f0, > peraggstate=peraggstate@entry=0x2b5efd0, > pergroupstate=pergroupstate@entry=0x8) at nodeAgg.c:468 > 468 if (pergroupstate->noTransValue) > (gdb) bt > #0 advance_transition_function at nodeAgg.c:468 > #1 0x00000000005c3494 in advance_aggregates at nodeAgg.c:624 > #2 0x00000000005c3dc2 in agg_fill_hash_table at nodeAgg.c:1640 > #3 ExecAgg (node=node@entry=0x2b5c5f0) at nodeAgg.c:1338 > > (gdb) print pergroupstate->noTransValue > Cannot access memory at address 0x11 > (gdb) print pergroupstate > $1 = (AggStatePerGroup) 0x8 > > My guess is something is scribbling over the pergroup memory, or maybe > the memory context gets released, or something. In any case, it's easily > reproducible, and apparently deterministic (always exactly the same > values, no randomness).
BTW the fact that 'make installcheck' and 'make check' both pass yet a simple query crashes, suggests there are no regression tests testing the batching properly. Which should be part of the patch, I believe. regards Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
