Re: Mark all GUC variable as PGDLLIMPORT - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Mark all GUC variable as PGDLLIMPORT
Date
Msg-id 20220219000218.rmhshnd7mxlr7wbh@alap3.anarazel.de
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Andres Freund <andres@anarazel.de>)
Responses Re: Mark all GUC variable as PGDLLIMPORT  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hi,

On 2022-02-15 08:06:58 -0800, Andres Freund wrote:
> The more I think about it the more I'm convinced that if we want to do this,
> we should do it for variables and functions.

Btw, if we were to do this, we should just use -fvisibility=hidden everywhere
and would see the same set of failures on unixoid systems as on windows. Of
course only in in-core extensions, but it'd still be better than nothing.

I proposed using -fvisibility=hidden in extensions:
https://postgr.es/m/20211101020311.av6hphdl6xbjbuif@alap3.anarazel.de

Mostly because using explicit symbol exports makes it a lot easier to build
extensions libraries on windows (with meson, but also everything built outside
of postgres with msvc). But also because it makes function calls *inside* an
extension have noticeably lower overhead. And it makes the set of symbols
exported smaller.


One problem I encountered was that it's actually kind of hard to set build
flags only for extension libraries:
https://postgr.es/m/20220111025328.iq5g6uck53j5qtin%40alap3.anarazel.de

But if we added explicit exports to everything we export, we'd not need to
restrict the use of -fvisibility=hidden to extension libraries anymore. Would
get decent error messages on all platforms.


Subsequently we could yield a bit of performance from critical paths by
marking selected symbols as *not* exported. That'd make them a tad cheaper to
call and allow the optimizer more leeway.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Race conditions in 019_replslot_limit.pl
Next
From: Peter Geoghegan
Date:
Subject: Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations