Re: gs_group_1 crashing on 13beta2/s390x
От | Christoph Berg |
---|---|
Тема | Re: gs_group_1 crashing on 13beta2/s390x |
Дата | |
Msg-id | 20200925143735.GH293907@msg.df7cb.de обсуждение исходный текст |
Ответ на | Re: gs_group_1 crashing on 13beta2/s390x (Christoph Berg <myon@debian.org>) |
Ответы |
Re: gs_group_1 crashing on 13beta2/s390x
Re: gs_group_1 crashing on 13beta2/s390x |
Список | 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 по дате отправления: