Re: JIT breaks PostGIS

From: Christoph Berg <myon(at)debian(dot)org>
To: Darafei "Komяpa" Praliaskouski <me(at)komzpa(dot)net>
Cc: Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: JIT breaks PostGIS
Date: 2018-07-25 19:05:33
Message-ID: 20180725190533.GA23966@msg.df7cb.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Re: Darafei "Komяpa" Praliaskouski 2018-07-23 <CAC8Q8t+=17oZ4TZGcPn-1BaTCO0_45TBxoc2AssG1Y9A9B6SKQ(at)mail(dot)gmail(dot)com>
> > It looks to me like it's a LLVM issue, specifically
> > https://bugs.llvm.org/show_bug.cgi?id=34424
> > fixed in LLVM 5+.
> >
>
> Thank you for your investigation.

Thanks!

> > 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?

> If Christoph decides to keep LLVM enabled for 11 on that platform, as he is
> recommended upthread by Tom, that would mean that PostGIS can't be packaged
> at all, and all the people who need it will have to stay on Postgres 10.

We'll definitely need to find a proper fix, not shipping PostGIS is
not an option.

> If PostGIS decides not to implement the check, and instead tweaks test
> runner to execute `set jit to off;` before tickets.sql, then Postgres 11 on
> that platform will have a known way to segfault it, even without superuser
> rights, as jit GUC is tweakable by anyone.

Not a good option, ack.

> 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, 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...

> 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.

Christoph

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2018-07-25 19:11:43 Re: JIT breaks PostGIS
Previous Message Nico Williams 2018-07-25 18:39:19 Re: Early WIP/PoC for inlining CTEs