Re: PostgreSQL 12, JIT defaults

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

>
>
> On October 8, 2018 10:16:54 AM PDT, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
> wrote:
> >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?
>
> To me that seems like an llvm / JIT independent piece of infrastructure.
> It'd probably be good if we had a catversion like thing to track ABI
> compatibility, but how to do so without making development unduly painful
> is less clear to me.
>

I am thinking so simple number should be good enough. We can require
equality - Just I need a signal so some is wrong - better than Postgres
crash.

>
> Andres
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>