Re: gs_group_1 crashing on 13beta2/s390x - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: gs_group_1 crashing on 13beta2/s390x
Date
Msg-id 20200925143735.GH293907@msg.df7cb.de
Whole thread Raw
In response to Re: gs_group_1 crashing on 13beta2/s390x  (Christoph Berg <myon@debian.org>)
Responses Re: gs_group_1 crashing on 13beta2/s390x
Re: gs_group_1 crashing on 13beta2/s390x
List pgsql-hackers
I poked around with the SET in the offending tests, and the crash is
only present if `set jit_above_cost = 0;` is present. Removing that
makes it pass. Removing work_mem or enable_hashagg does not make a
difference. llvm version is 10.0.1.


Test file:

--
-- Compare results between plans using sorting and plans using hash
-- aggregation. Force spilling in both cases by setting work_mem low
-- and altering the statistics.
--

create table gs_data_1 as
select g%1000 as g1000, g%100 as g100, g%10 as g10, g
   from generate_series(0,1999) g;

analyze gs_data_1;
alter table gs_data_1 set (autovacuum_enabled = 'false');
update pg_class set reltuples = 10 where relname='gs_data_1';

SET work_mem='64kB';

-- Produce results with sorting.

set enable_hashagg = false;
set jit_above_cost = 0; -- remove this to remove crash

explain (costs off)
select g100, g10, sum(g::numeric), count(*), max(g::text)
from gs_data_1 group by cube (g1000, g100,g10);

create table gs_group_1 as
select g100, g10, sum(g::numeric), count(*), max(g::text)
from gs_data_1 group by cube (g1000, g100,g10);



Christoph



pgsql-hackers by date:

Previous
From: Christoph Berg
Date:
Subject: Re: gs_group_1 crashing on 13beta2/s390x
Next
From: Christoph Berg
Date:
Subject: Re: gs_group_1 crashing on 13beta2/s390x