From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Jacob Champion <pchampion@vmware.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: Daniel Gustafsson <daniel@yesql.se>
Cc: info@cspug.cz
Subject: Re: Preventing abort() and exit() calls in libpq
Date: Fri, 9 Jul 2021 02:59:52 -0700
Message-ID: <20210709095952.GA2945708@rfd.leadboat.com> (raw)
In-Reply-To: <1288324.1625352260@sss.pgh.pa.us>
References: <202107021459.7c2dkzyg5lua@alvherre.pgsql>
<819502.1625239217@sss.pgh.pa.us>
<20210703001639.GB2374652@rfd.leadboat.com>
<1231771.1625321413@sss.pgh.pa.us>
<1233492.1625323559@sss.pgh.pa.us>
<20210703214658.GA2421985@rfd.leadboat.com>
<1288324.1625352260@sss.pgh.pa.us>
On Sat, Jul 03, 2021 at 06:44:20PM -0400, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Sat, Jul 03, 2021 at 10:45:59AM -0400, Tom Lane wrote:
> >> What I'm now thinking about is restricting the test to only be run on
> >> platforms where use of foo.a libraries is deprecated, so that we can
> >> be pretty sure that we won't hit this situation. Even if we only
> >> run the test on Linux, that'd be plenty to catch any mistakes.
>
> > Hmm. Static libraries are the rarer case on both AIX and Linux, but I'm not
> > aware of a relevant deprecation on either platform. If it comes this to, I'd
> > be more inclined to control the Makefile rule with an environment variable
> > (e.g. ENFORCE_LIBC_CALL_RESTRICTIONS) instead of reacting to the platform.
>
> That'd require buildfarm owner intervention, as well as intervention
> by users. Which seems like exporting our problems onto them. I'd
> really rather not go that way if we can avoid it.
I like that goal, though we'll have to see how difficult it proves. As of
today, a GNU/Linux user building against static OpenLDAP will get a failure,
right? That would export work onto that user, spuriously. Since the non-AIX
user count dwarfs the AIX user count, expect a user complaint from non-AIX
first.
We'd get something like 95% of the value by running the test on one Windows
buildfarm member and one non-Windows buildfarm member. If you did gate the
check on an environment variable, there would be no need to angle for broad
adoption. Still, I agree avoiding that configuration step is nice, all else
being equal. A strategy not having either of those drawbacks would be to skip
the test if libpq.so contains a definition of libpq_unbind(). If any other
dependency contains exit calls, we'd likewise probe for one symbol of that
library and skip the test if presence of that symbol reveals static linking.
(That's maintenance-prone in its own way, but a maintenance-free strategy has
not appeared.)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: noah@leadboat.com, tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, michael@paquier.xyz, pchampion@vmware.com, daniel@yesql.se, info@cspug.cz
Subject: Re: Preventing abort() and exit() calls in libpq
In-Reply-To: <20210709095952.GA2945708@rfd.leadboat.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox