Re: PostgreSQL 12, JIT defaults

po 8. 10. 2018 v 17:59 odesílatel Andres Freund <andres(at)anarazel(dot)de> napsal:

> Hi,
>
> On 2018-10-08 11:43:42 -0400, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> > > On October 8, 2018 8:03:56 AM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > >> A look in guc.c shows that jit defaults to "on" whether or not JIT is
> > >> enabled at compile time.
> > >> This seems, at best, rather user-unfriendly.
> > >> And it's not like our conventions for other compile-option-affected
> > >> GUCs, eg the SSL ones.
> >
> > > That was intentional, even though it perhaps should be better
> documented. That allows a distro to build and distribute pg without llvm
> enabled, but then have the JIT package with all the dependencies
> separately. The pg yum packages do so.
> >
> > I'm not following. A distro wishing to do that would configure
> > --with-llvm, not without, and then simply split up the build results
> > so that the JIT stuff is in a separate subpackage.
>
> Well, that'd then leave you with one more state (LLVM configured but not
> installed, LLVM configured and installed, LLVM disabled and arguably
> LLVM disabled but installed), but more importantly if you compile
> without llvm enabled, you can still install a different extension that
> would do JIT. You'd just have to set jit_provider = xyz, and it'd
> work. If we made the generic JIT code depend on LLVM that'd end up
> working pretty weirdly. I guess we could set jit_provider = ''
> something if instead of hardcoding llvmjit if LLVM is disabled.
>

>
> > If you configured --without-llvm then the resulting core code is (one
> > hopes) entirely incapable of using JIT, and it'd be better if the GUC
> > settings reflected that..
>
> That's not really the case, no. It controls whether the LLVM using jit
> provider is built, not whether the generic JIT handling code is
> available. Given that the generic code has no dependencies, there seems
> little reason to do that differently?
>

I can accept this logic, but it looks very fragile. Can be there some
safeguard against using wrong version or wrong API?

> Greetings,
>
> Andres Freund
>