po 8. 10. 2018 v 19:24 odesÃlatel Andres Freund <and...@anarazel.de> napsal:
> > > On October 8, 2018 10:16:54 AM PDT, Pavel Stehule <pavel.steh...@gmail.com> > wrote: > >po 8. 10. 2018 v 17:59 odesÃlatel Andres Freund <and...@anarazel.de> > >napsal: > > > >> Hi, > >> > >> On 2018-10-08 11:43:42 -0400, Tom Lane wrote: > >> > Andres Freund <and...@anarazel.de> writes: > >> > > On October 8, 2018 8:03:56 AM PDT, Tom Lane <t...@sss.pgh.pa.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. >
