Re: pg13 PGDLLIMPORT list

On Tue, 21 Jan 2020 at 12:49, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Jan 21, 2020 at 08:34:05AM +0530, Amit Kapila wrote:
> > As such no objection, but I am not sure if the other person need it on
> > back branches as well.  Are you planning to commit this, or if you
> > want I can take care of it?
>
> Thanks for the reminder.  Done now.  I have also switched the
> surrounding parameters while on it to not be inconsistent.

While speaking of PGDLLIMPORT, I wrote a quick check target in the
makefiles for some extensions I work on. It identified the following
symbols as used by the extensions but not exported:

XactLastRecEnd (xlog.h)
criticalSharedRelcachesBuilt   (relcache.h)
hot_standby_feedback   (walreceiver.h)
pgstat_track_activities  (pgstat.h)
WalRcv  (walreceiver.h)
wal_receiver_status_interval (walreceiver.h)
wal_retrieve_retry_interval (walreceiver.h)

Of those, XactLastRecEnd is by far the most important.

Failure to export pgstat_track_activities is a bug IMO, since it's
exported by inline functions pgstat_report_wait_start() and
pgstat_report_wait_end() in pgstat.h

criticalSharedRelcachesBuilt is useful in extensions that may do genam
systable_beginscan() etc in functions called both early in startup and
later on.

hot_standby_feedback can be worked around by reading the GUC via the
config options interface. But IMO all GUC symbols should be
PGDLLEXPORTed, especially since we lack an interface for extensions to
read arbitrary GUC values w/o formatting to string then parsing the
string.

wal_receiver_status_interval and wal_retrieve_retry_interval are not
that important, but again they're GUCs.

Being able to see WalRcv is very useful when running extension code on
a streaming physical replica, where you want to make decisions based
on what's actually replicated.

Anyone object to exporting these?


-- 
 Craig Ringer                   http://www.2ndQuadrant.com/
 2ndQuadrant - PostgreSQL Solutions for the Enterprise