Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rmjIJ-009WDN-5E for pgsql-bugs@arkaria.postgresql.org; Tue, 19 Mar 2024 23:54:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rmjIG-001HlG-Ok for pgsql-bugs@arkaria.postgresql.org; Tue, 19 Mar 2024 23:54:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rmjIG-001Hl8-GW for pgsql-bugs@lists.postgresql.org; Tue, 19 Mar 2024 23:54:56 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rmjID-005S4Y-TO for pgsql-bugs@lists.postgresql.org; Tue, 19 Mar 2024 23:54:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=momjian.us; s=2024011501; h=In-Reply-To:Content-Transfer-Encoding:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-ID:Content-Description; bh=RApELBHncqGji9/u+KJ8W2AZqTc7VZtL4ZNM/LlC9RI=; b=DBSiiknLaRpDY8WXc6v3TVCSmx bw9yc9APmLn9fQLcDNOjSxKSdCwGVpw6DzT1fzsF9C2+1O9AIy3rFqcaXsoynFUOEgZtGKaT3+Utd wzkYQ0nXVACybAHemkWeA9pLZy8yngj73BqbRBfFG90Y9s3rtz9eK+jUGdH1M6Btq6zY44nLY6GkA xaSSzRRrYJXGY3MF42XJKXpc/4sQafO2DAPhOVUHPO5vE0/XbEIr6I6pea1QRnLJRAejMmE/sDurA 444x8EA1WLK9vgNl9UfcFJAneOavkvp0TrWfGF23wMdIWTsliKUI3cYYm6inOa0jMyThxd0J47Dh1 YD7nsh7g==; Received: from bruce by momjian.us with local (Exim 4.96) (envelope-from ) id 1rmjI9-00CREC-2k; Tue, 19 Mar 2024 19:54:49 -0400 Date: Tue, 19 Mar 2024 19:54:49 -0400 From: Bruce Momjian To: Thomas Munro Cc: Tom Lane , Christophe Pettus , Andrew Dunstan , Wolfgang Walther , PostgreSQL Bugs Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded Message-ID: References: <855a1b16-0dc0-42b2-8f90-79eb49cf2893@technowledgy.de> <3561573.1710771812@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Mar 19, 2024 at 11:48:50AM +1300, Thomas Munro wrote: > On Tue, Mar 19, 2024 at 10:17 AM Thomas Munro wrote: > > ... (though my patch could be a little sneakier and steal > > all the bytes right up to the = sign to get more space for our > > message!). > > Here's one like that. No musl here -- does this work Wolfgang? Do we > think it's generous enough with space in practice that we could just > always do this for __linux__ systems without anyone noticing (ie > including glibc users)? Should we be more specific about which LD_* > variables? Do people not doing hacking/testing ever really set those, > eg on production servers? This code path was once used by up to a > dozen or so OSes but they're all dead, only Linux, Solaris and macOS > left, and I don't have any reason to think they suffer from this > problem and Macs don't even follow the SysV LD_ naming convention, > hence gating on Linux. So this would truncate the process title on all Linux that have an LD_ environment entry, even those without musl? -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.