From: | Christoph Berg <myon(at)debian(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Re: gs_group_1 crashing on 13beta2/s390x |
Date: | 2020-09-25 15:29:07 |
Message-ID: | 20200925152907.GI293907@msg.df7cb.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Re: To Tom Lane
> 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.
I put jit_above_cost=0 into postgresql.conf and ran "make installcheck"
again. There are more crashes:
From src/test/regress/sql/interval.sql:
2020-09-25 17:00:25.130 CEST [8135] LOG: Serverprozess (PID 8369) wurde von Signal 11 beendet: Speicherzugriffsfehler
2020-09-25 17:00:25.130 CEST [8135] DETAIL: Der fehlgeschlagene Prozess führte aus: select avg(f1) from interval_tbl;
From src/test/regress/sql/tid.sql:
2020-09-25 17:01:20.593 CEST [8135] LOG: Serverprozess (PID 9015) wurde von Signal 11 beendet: Speicherzugriffsfehler
2020-09-25 17:01:20.593 CEST [8135] DETAIL: Der fehlgeschlagene Prozess führte aus: SELECT max(ctid) FROM tid_tab;
From src/test/regress/sql/collate*.sql:
2020-09-25 17:07:17.852 CEST [8135] LOG: Serverprozess (PID 12232) wurde von Signal 11 beendet: Speicherzugriffsfehler
2020-09-25 17:07:17.852 CEST [8135] DETAIL: Der fehlgeschlagene Prozess führte aus: SELECT min(b), max(b) FROM collate_test1;
From src/test/regress/sql/plpgsql.sql:
2020-09-25 17:11:56.495 CEST [8135] LOG: Serverprozess (PID 15562) wurde von Signal 11 beendet: Speicherzugriffsfehler
2020-09-25 17:11:56.495 CEST [8135] DETAIL: Der fehlgeschlagene Prozess führte aus: select * from returnqueryf();
Contrary to the others this one is not related to aggregates:
-- test RETURN QUERY with dropped columns
create table tabwithcols(a int, b int, c int, d int);
insert into tabwithcols values(10,20,30,40),(50,60,70,80);
create or replace function returnqueryf()
returns setof tabwithcols as $$
begin
return query select * from tabwithcols;
return query execute 'select * from tabwithcols';
end;
$$ language plpgsql;
select * from returnqueryf();
alter table tabwithcols drop column b;
select * from returnqueryf();
alter table tabwithcols drop column d;
select * from returnqueryf();
alter table tabwithcols add column d int;
select * from returnqueryf();
drop function returnqueryf();
drop table tabwithcols;
src/test/regress/sql/rangefuncs.sql:
2020-09-25 17:16:04.209 CEST [8135] LOG: Serverprozess (PID 17372) wurde von Signal 11 beendet: Speicherzugriffsfehler
2020-09-25 17:16:04.209 CEST [8135] DETAIL: Der fehlgeschlagene Prozess führte aus: select * from usersview;
src/test/regress/sql/alter_table.sql:
2020-09-25 17:21:36.187 CEST [8135] LOG: Serverprozess (PID 19217) wurde von Signal 11 beendet: Speicherzugriffsfehler
2020-09-25 17:21:36.187 CEST [8135] DETAIL: Der fehlgeschlagene Prozess führte aus: update atacc3 set test2 = 4 where test2 is null;
src/test/regress/sql/polymorphism.sql:
2020-09-25 17:23:55.509 CEST [8135] LOG: Serverprozess (PID 21010) wurde von Signal 11 beendet: Speicherzugriffsfehler
2020-09-25 17:23:55.509 CEST [8135] DETAIL: Der fehlgeschlagene Prozess führte aus: select myleast(1.1, 0.22, 0.55);
2020-09-25 17:28:26.222 CEST [8135] LOG: Serverprozess (PID 22325) wurde von Signal 11 beendet: Speicherzugriffsfehler
2020-09-25 17:28:26.222 CEST [8135] DETAIL: Der fehlgeschlagene Prozess führte aus: select f.longname from fullname f;
(stopping here)
There are also a lot of these log lines (without prefix):
ORC error: No callback manager available for s390x-ibm-linux-gnu
Is that worrying? I'm not sure but I think I've seen these on other
architectures as well.
I guess that suggests two things:
* jit is not ready for prime time on s390x and I should disable it
* jit is not exercised enough by "make installcheck"
Christoph
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Nancarrow | 2020-09-25 15:52:50 | Re: Parallel INSERT (INTO ... SELECT ...) |
Previous Message | Christoph Berg | 2020-09-25 14:37:35 | Re: gs_group_1 crashing on 13beta2/s390x |