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 20220506234924.6mxxotl3xl63db3l@alap3.anarazel.de
Whole thread Raw
In response to Re: Mark all GUC variable as PGDLLIMPORT  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Mark all GUC variable as PGDLLIMPORT  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Hi,

On 2022-04-08 08:42:38 -0400, Robert Haas wrote:
> On Wed, Apr 6, 2022 at 7:56 PM Michael Paquier <michael@paquier.xyz> wrote:
> > On Wed, Apr 06, 2022 at 12:57:29AM +0700, John Naylor wrote:
> > > For these two patches, I'd say a day or two after feature freeze is a
> > > reasonable goal.
> >
> > Yeah.  For patches as invasive as the PGDLLIMPORT business and the
> > frontend error refactoring, I am also fine to have two exceptions with
> > the freeze deadline.
> 
> Done now.

Just noticed that
extern sigset_t UnBlockSig,
             BlockSig,
             StartupBlockSig;
are unadorned.


There's also a number of variables that are only declared in .c files that
!windows can still access. Some likely aren't worth caring about, but some
others are underlying GUCs, so we probably do? E.g.
CommitDelay
CommitSiblings
default_tablespace
ignore_checksum_failure
ignore_invalid_pages
Log_disconnections
ssl_renegotiation_limit
temp_tablespaces
Unix_socket_group
Unix_socket_permissions
wal_level_options

Likely don't care:
dynamic_shared_memory_options
gistBufferingOptValues
recovery_target_action_options
ssl_protocol_versions_info

Also noticed that the bbsink_ops variables are const, instead of static const,
was that intentional?

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Possible corruption by CreateRestartPoint at promotion
Next
From: Robert Haas
Date:
Subject: Re: make MaxBackends available in _PG_init