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 1rp7u3-005CVz-F1 for pgsql-bugs@arkaria.postgresql.org; Tue, 26 Mar 2024 14:35:51 +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 1rp7u2-00G7Ki-5V for pgsql-bugs@arkaria.postgresql.org; Tue, 26 Mar 2024 14:35:50 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rp7u1-00G7KQ-TC for pgsql-bugs@lists.postgresql.org; Tue, 26 Mar 2024 14:35:49 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rp7tx-006XsG-Uy for pgsql-bugs@lists.postgresql.org; Tue, 26 Mar 2024 14:35:48 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 42QEZh9V2822008; Tue, 26 Mar 2024 10:35:43 -0400 From: Tom Lane To: walther@technowledgy.de cc: Bruce Momjian , Thomas Munro , Peter Eisentraut , Christophe Pettus , Andrew Dunstan , PostgreSQL Bugs , Robert Haas Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded In-reply-to: <672a33fb-2ce9-4fcb-8707-c8d6e56c3ed5@technowledgy.de> References: <36690fcf-f0c8-4d60-af49-6a7efa0e2b14@technowledgy.de> <2293691d-2adb-4502-b956-73e79dc43c55@technowledgy.de> <2712255.1711408465@sss.pgh.pa.us> <672a33fb-2ce9-4fcb-8707-c8d6e56c3ed5@technowledgy.de> Comments: In-reply-to walther@technowledgy.de message dated "Tue, 26 Mar 2024 08:43:54 +0100" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2822006.1711463743.1@sss.pgh.pa.us> Date: Tue, 26 Mar 2024 10:35:43 -0400 Message-ID: <2822007.1711463743@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk walther@technowledgy.de writes: > The second patch potentially solves the problem of PS_USE_NONE not being > tested. Of course you could also set up a buildfarm animal on some other > platform, which is sure to fall through to PS_USE_NONE, but that seems > to have not worked in the past: > Thomas Munro: >> I dimly recall that it turned out that PS_USE_NONE was >> actually broken for a while without anyone noticing I think what Thomas is recollecting is this: Author: Tom Lane Branch: master Release: REL_15_BR [0fb6954aa] 2022-03-27 12:57:46 -0400 Branch: REL_14_STABLE Release: REL_14_3 [3f7a59c59] 2022-03-27 12:57:52 -0400 Branch: REL_13_STABLE Release: REL_13_7 [9016a2a3d] 2022-03-27 12:57:57 -0400 Fix breakage of get_ps_display() in the PS_USE_NONE case. Commit 8c6d30f21 caused this function to fail to set *displen in the PS_USE_NONE code path. If the variable's previous value had been negative, that'd lead to a memory clobber at some call sites. We'd managed not to notice due to very thin test coverage of such configurations, but this appears to explain buildfarm member lorikeet's recent struggles. Credit to Andrew Dunstan for spotting the problem. Back-patch to v13 where the bug was introduced. Discussion: https://postgr.es/m/136102.1648320427@sss.pgh.pa.us The problem wasn't lack of coverage, it was that the failure was intermittent and erratic enough to be very hard to diagnose. I think that's more bad luck than anything else. regards, tom lane