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

On October 8, 2018 10:29:56 AM PDT, Pavel Stehule <pavel.stehule@gmail.com> wrote:
>po 8. 10. 2018 v 19:24 odesílatel Andres Freund <andres@anarazel.de>
>napsal:
>
>>
>>
>> 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 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.

It'd cause constant conflicts and / or we would regularly forget updating it. It's not that trivial to determine what
influencesABI compatibility. 

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