Re: PostgreSQL 12, JIT defaults - Mailing list pgsql-hackers

On October 8, 2018 10:16:54 AM PDT, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>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?

To me that seems like an llvm / JIT independent piece of infrastructure.  It'd probably be good if we had a catversion
likething to track ABI compatibility, but how to do so without making development unduly painful is less clear to me. 

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