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
