On Wed, Feb 19, 2020 at 08:16:36PM +0100, Tomas Vondra wrote: > 5) Assert(nbuckets > 0); > ... > This however quickly fails on this assert in BuildTupleHashTableExt (see > backtrace1.txt): > > Assert(nbuckets > 0); > > The value is computed in hash_choose_num_buckets, and there seem to be > no protections against returning bogus values like 0. So maybe we should > return > > Min(nbuckets, 1024) > > or something like that, similarly to hash join. OTOH maybe it's simply > due to agg_refill_hash_table() passing bogus values to the function? > > > 6) Another thing that occurred to me was what happens to grouping sets, > which we can't spill to disk. So I did this: > > create table t2 (a int, b int, c int); > > -- run repeatedly, until there are about 20M rows in t2 (1GB) > with tx as (select array_agg(a) as a, array_agg(b) as b > from (select a, b from t order by random()) foo), > ty as (select array_agg(a) AS a > from (select a from t order by random()) foo) > insert into t2 select unnest(tx.a), unnest(ty.a), unnest(tx.b) > from tx, ty; > > analyze t2; > ... > > which fails with segfault at execution time: > > tuplehash_start_iterate (tb=0x18, iter=iter@entry=0x2349340) > 870 for (i = 0; i < tb->size; i++) > (gdb) bt > #0 tuplehash_start_iterate (tb=0x18, iter=iter@entry=0x2349340) > #1 0x0000000000654e49 in agg_retrieve_hash_table_in_memory ... > > That's not surprising, because 0x18 pointer is obviously bogus. I guess > this is simply an offset 18B added to a NULL pointer?
I did some investigation, have you disabled the assert when this panic happens? If so, it's the same issue as "5) nbucket == 0", which passes a zero size to allocator when creates that endup-with-0x18 hashtable. Sorry my testing env goes weird right now, haven't reproduced it yet. -- Adam Lee
