Re: __pg_log_level in anonynous enum should be initialized? (Was: pgsql: Change SHA2 implementation based on OpenSSL to use EVP digest ro) - Mailing list pgsql-hackers

Michael Paquier <michael@paquier.xyz> writes:
> It looks like this commit has broken prairiedog as follows:
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prairiedog&dt=2020-09-28%2005%3A45%3A55
> ld: common symbols not allowed with MH_DYLIB output format with the
> -multi_module option
> ../../../src/common/libpgcommon_shlib.a(logging_shlib.o) definition of
> common ___pg_log_level (size 4)

> Looking around, I have found a similar report from MacPorts and 10.4,
> leading to the fact that it may be better to initialize
> __pg_log_level:
> https://trac.macports.org/ticket/19829

I experimented and confirmed that explicitly initializing __pg_log_level
would suppress this build error on prairiedog.  However, I'm not sure
that doing so is a good idea, because it seems to me that this animal
has accidentally saved us from a serious design error.  IMO it is quite
unacceptable for libpq to contain either a forced write to stderr or a
forced exit(1).  It should be reporting the failure back to the calling
application, instead.  So the error handling in this patch needs to be
reconsidered.

Since prairiedog is not likely to be around forever, I propose that
we ought to enforce this going forward by arranging for common/logging.c
to not get built into the libpgcommon_shlib library variant.

            regards, tom lane