Hi Peter, All,
First question: Why do we currently use RTLD_GLOBAL loading extension libraries, but take pains ([1]) to make things work without RTLD_GLOBAL. It seems like it'd be both safer to RTLD_LOCAL on platforms supporting it (or equivalent), as well as less error-prone because we'd be less likely to depend on it like we did e.g. during transforms development. It seems error prone because on systmes I'm aware of (IOW linux ;)) conflicting symbols will not cause errors. Neither when there's a conflict between a .so and the main binary, nor between different shlibs. My reading of glibc's ld is that the search order for unresolved references in a .so is main binary, and then other RTLD_GLOBAL shared libraries in order of time they're loaded. Right now it appears that e.g. hstore_plperl has some issue, building with RTLD_LOCAL makes its test fail. Which means it'll probably not work on some platforms. I think using RTLD_LOCAL on most machines would be a much better idea. I've not found proper explanations why GLOBAL is used. We started using it ages ago, with [2], but that commit contains no explanation, and a quick search didn't show up anything either. Peter? Secondly: For JITing internal & C operators, and other functions referenced in JITed code, can be inlined if the definition is available in a suitable form. The details how that works don't matter much here. For my jitting work I've so far treated symbols of binaries and all referenced extensions as being part of a single namespace. Currently the order in which symbols with multiple definitions were looked up was in essentially in filesystem order. While I'm not aware of any observable problems, reviewing that decision I think that's a terrible idea. First and foremost it seems obviously wrong to not load symbols from the main postgres binary first. But leaving that aside, I'm uncomfortable doing inlining between shlibs for JITing, because that can lead to symbols beeing reloaded differently between non JITed code (where all external libraries loaded in the current library are searched in load/usage order) and JITed code (where the symbols would be resolved according to some static order). I'm about to rewrite it so that functions are inlined just from the main binary, or the basename of the shared library explicitly referenced in the function definition. That's still different, but at least easy to understand. But that still means there's inconsistent order between different methods of execution, which isn't great. Comments? Greetings, Andres Freund [1] http://archives.postgresql.org/message-id/2652.1475512158%40sss.pgh.pa.us [2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c87bc779d4e9f109e92f8b8f1dfad5d6739f8e97
