Re: 9.5: Better memory accounting, towards memory-bounded HashAgg

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(at)entry=0x2b5c5f0,
> peraggstate=peraggstate(at)entry=0x2b5efd0,
> pergroupstate=pergroupstate(at)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(at)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