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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to