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
