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

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: 9.5: Better memory accounting, towards memory-bounded HashAgg
Date: 2014-12-21 19:31:32
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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.


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2014-12-21 19:50:09 Re: Add min and max execute statement time in pg_stat_statement
Previous Message Andrew Dunstan 2014-12-21 19:22:10 Re: controlling psql's use of the pager a bit more