Hi, On 2018-07-25 21:39:26 +0200, Christoph Berg wrote: > Re: Andres Freund 2018-07-25 > <20180725191143.sietxlbfehv24...@alap3.anarazel.de> > > I haven't investigated the details here. It certainly would be possible > > to have the _PG_init() of postgis's so force JIT to be off, and emit a > > warning. > > Isn't that too late, if postgis.so gets loaded by a query that is in > to process of being jit'ed?
Hm, I'd guess it'd still be fine, but I haven't thought it sufficiently through. > Different question, the other way round, is there a way to know that > all files needed to inline a query/extension are there? How does the > JIT machinery determine it can (try to) compile things? (That's > something extension packages might want to test for.) I'm not 100% sure I understand your question. Let me describe how it works, and maybe you can then rephrase afterwards? The way inlining works is that, when referencing a function, the bitcode summary file corresponding to it (either postgres.index.bc if builtin or $extension.index.bc if in an extension) gets opened. That contains metadata (name, number of instructions, ...) about the functions included in the indexed .bc files (which reside in $module/path/to/$file.bc). Those .bc files in turn are generated by clang -emit-llvm. The inlining machinery looks up functions in the corresponding .index.bc, checks whether they are smaller than the instruction limit, and inlines them if below. If a function is not in the summary, or it is too large, it'll just generate an external function call. It's perfectly normal to have too large functions and functions that aren't present (e.g. random libraries including libc). What precisely would you want to test? Greetings, Andres Freund