Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1nIg-0002rV-9A for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Jul 2021 10:00:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1m1nId-0001Ru-Va for pgsql-hackers@arkaria.postgresql.org; Fri, 09 Jul 2021 09:59:59 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1nId-0001RW-Gq for pgsql-hackers@lists.postgresql.org; Fri, 09 Jul 2021 09:59:59 +0000 Received: from mail-pf1-x42b.google.com ([2607:f8b0:4864:20::42b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1m1nIb-0007bF-4u for pgsql-hackers@postgresql.org; Fri, 09 Jul 2021 09:59:58 +0000 Received: by mail-pf1-x42b.google.com with SMTP id m83so609396pfd.0 for ; Fri, 09 Jul 2021 02:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leadboat.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Ste5c7NVBMHyjygT+0yhRY9RXT1AGwwoIs51lr0rBR0=; b=Dzg+a6p/RBvTb8yXqta7iUUixYmcKz/7l6YsEdo//KCLHfClHuOmoDswCfAYxFZ3z6 wPwH9uagP+RSNgFTZmeGDlnD6tyjkzZn+4Sk0onOX41VY4+83B2nM3yvIwhZZgQFbBrf qmhdBO6Tpl+1/nHDrYI1ToXfPKd+mqx7NPwWo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=Ste5c7NVBMHyjygT+0yhRY9RXT1AGwwoIs51lr0rBR0=; b=fXn9Zwco34nO8VCFjU6+5/cfSWAcJr9ftWif6wWJG8oQejdgDyednGIZi97C4ARjMT dvspREeVub/jwz9MrdUH4qgUZHvsIASbmuk1aMZS13jfr9nR+ia1V4vovuv3OZZ2WFoy yfVT8QagXXivsQMyYBP8wGoZ3MjUT5Rj8LEPqOIajP2WCMQjgfDR7oRrxrPESBs+dTha tsyyl3jRo8Q1fOivpCY7mu6qUmsrx5WJwpltwLMc9OLsFBTpVNbRjdi2atRo6FyPLutc ibaYK82ALpZBp/RJG67Mk8m1V4BS0nxJnchwnu/xPwrGubY1c35HxNrlYkuEYBov1wfF 4YDw== X-Gm-Message-State: AOAM530n/vtUqi4Spqd85yPnraF1uyxAhJv9jqIb585FB/d7vxFuCGbE k/qQix1gkG4zncBPJcKnJhP2Mg== X-Google-Smtp-Source: ABdhPJydWepyGv0KX6Qki7pyARbFxh1DCBV6OIXasqV72gt1oVYA1WIS4X5wR73q8kdDq443wlijxw== X-Received: by 2002:a63:d80a:: with SMTP id b10mr37254660pgh.47.1625824795182; Fri, 09 Jul 2021 02:59:55 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::46]) by smtp.gmail.com with ESMTPSA id h24sm5806576pfn.180.2021.07.09.02.59.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jul 2021 02:59:54 -0700 (PDT) Date: Fri, 9 Jul 2021 02:59:52 -0700 From: Noah Misch To: Tom Lane Cc: Alvaro Herrera , Michael Paquier , Jacob Champion , "pgsql-hackers@postgresql.org" , Daniel Gustafsson , info@cspug.cz Subject: Re: Preventing abort() and exit() calls in libpq Message-ID: <20210709095952.GA2945708@rfd.leadboat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1288324.1625352260@sss.pgh.pa.us> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Jul 03, 2021 at 06:44:20PM -0400, Tom Lane wrote: > Noah Misch 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.)