From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Christoph Berg <myon(at)debian(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [patch] Support LLVM 7 |
Date: | 2018-09-20 17:30:09 |
Message-ID: | 20180920173009.ywi5grbotl7um65p@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2018-09-20 15:18:14 +0200, Christoph Berg wrote:
> Re: To Andres Freund 2018-09-20 <20180920081044(dot)GA16897(at)msg(dot)df7cb(dot)de>
> > > > 2018-09-15 10:49:25.052 UTC [26458] DETAIL: Failed process was running: SELECT '' AS tf_12, BOOLTBL1.*, BOOLTBL2.*
> > > > FROM BOOLTBL1, BOOLTBL2
> > > > WHERE BOOLTBL2.f1 <> BOOLTBL1.f1;
> > > > 2018-09-15 10:49:25.052 UTC [26458] LOG: terminating any other active server processes
> > >
> > > Hm. Is there any chance to get a backtrace for this one? This could,
> > > although I think less likely so, also be a postgres issue
> > > (e.g. generating code for the wrong microarch).
> >
> > I'll see if I can find a porterbox to get a backtrace.
Hm, this is pretty helpful. Sorry to ask, but could you a) turn on
jit_debugging_support (connection start) b) jit_dump_bitcode.
Then reproduce again. After that, it'd be helpful to get:
1) /proc/cpuinfo
2) the "newest" *.bc file from the data directory
3) a backtrace
4) gdb disassemble at the point of the error.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-09-20 17:32:38 | Re: [patch] Support LLVM 7 |
Previous Message | Andres Freund | 2018-09-20 17:27:01 | Re: Query is over 2x slower with jit=on |