po 8. 10. 2018 v 17:59 odesílatel Andres Freund <andres@anarazel.de> napsal:
Hi,
On 2018-10-08 11:43:42 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On October 8, 2018 8:03:56 AM PDT, Tom Lane <tgl@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?
