|From:||Andres Freund <andres(at)anarazel(dot)de>|
|Subject:||Use -fvisibility=hidden for shared libraries|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Currently postgres builds extension shared libraries (i.e. pretty much
everything but libpq) with global visibilty. I.e. symbols that are not
static will be visible from outside the shared library.
On the one platform where that behaviour is not available, namely
windows, we emulate it by analyzing the input files to the shared
library and exporting all the symbols therein.
For the meson build  proposal that turned out to be a bit more
verbose to implement than I'd liked. Thinking about the problem I
realized that, at least I think so, there's really no good reason to
force-export symbols in our shared libraries:
Because the number of symbols required from shared libraries is
typically small, and the majority of the symbols are generated via
PG_FUNCTION_INFO_V1, it isn't a lot of work to explicitly export the
I think this is a much more feasible proposal than, as has been
suggested in the past, using explicit visibility for the entire
backend. The amount of functions that'd need to be annotated in the
backend is huge, and I don't think we have a reasonable starting point
for limiting what we'd export.
There are a few extension libs that need manual export
annotations. These are libraries that are not just referenced by the
backend, but also from other extensions, e.g. for transforms.
The patch e.g. reduces the number of exported symbols for
- plpython: 61 -> 29
- plperl: 32 -> 17
- llvmjit: 84 -> 5
- postgres_fdw: 48 -> 15
- dict_snowball: 182 -> 8
Besides the smaller number of symbols (which can impact library load
times a bit, although the numbers here are likely small enough to not
matter), using -fvisibility=hidden also can improve code generation,
because it allows the compiler & linker to generate a plain function
call, rather than having to go through the elf symbol-interposition
The attached patch is a prototype of this idea.
|Next Message||Kyotaro Horiguchi||2021-11-01 02:40:19||Re: inefficient loop in StandbyReleaseLockList()|
|Previous Message||Masahiko Sawada||2021-11-01 01:54:31||Re: Skipping logical replication transactions on subscriber side|