Re: JIT breaks PostGIS

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

In response to

Responses

Browse pgsql-hackers by date

  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