From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Christoph Berg <myon(at)debian(dot)org> |
Cc: | Darafei "Komяpa" Praliaskouski <me(at)komzpa(dot)net>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: JIT breaks PostGIS |
Date: | 2018-07-25 19:11:43 |
Message-ID: | 20180725191143.sietxlbfehv245hb@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-07-25 21:05:33 +0200, Christoph Berg wrote:
> > > It'll only be an issue for extensions that throw c++ style exceptions. I
> > > don't think that rises to the level of disallowing any LLVM version <
> > > 5.0. I suggest postgis adds an error check to its buildprocess that
> > > refuses to run if jit is enabled and a too old version is used?
> >
> > Unfortunately that's not an option.
>
> Is it possible to disable JIT per extension, say by removing all .bc
> files for it, or via a PGXS variable? Or does this bug still trigger
> even without the .bc files for PostGIS?
I haven't investigated the details here. It certainly would be possible
to have the _PG_init() of postgis's so force JIT to be off, and emit a
warning.
There's no way to just force JIT off whenever anything involving postgis
is present in the query. Not installing the .bc files will prevent
inlining, but I don't think that's sufficient to prevent the problem in
all cases.
> > I think that a good way to deal with it will be to bump minimum required
> > version of LLVM to 5 on Postgres build, with a notice in docs that will say
> > that "you can build with lower version, but that will give you this and
> > this bug".
>
> Is LLVM << 5 generally acceptable for use with PostgreSQL
It is. Newer version wouldn't hurt though.
> , or should we look into getting a new version to distribute along
> with it on apt.postgresql.org? I'd rather like to avoid having to ship
> a compiler...
Well, you don't need to ship the compiler (clang), strictly
speaking. But yea.
> > It also may happen that a patch for LLVM can be applied to LLVM4 build in
> > Debian and brought in as an update, but such a plan should not be a default
> > one.
>
> That's actually a plan I like very much. Hopefully the patch is small
> and backpatchable.
It's not entirely trivial, and I suspect there's independent changes
making it not apply cleanly:
https://github.com/llvm-mirror/llvm/commit/ab3dba86f951a1bdfe01d3102e2850e607af791a
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2018-07-25 19:14:47 | Re: Early WIP/PoC for inlining CTEs |
Previous Message | Christoph Berg | 2018-07-25 19:05:33 | Re: JIT breaks PostGIS |