From: Tom Lane <tgl@sss.pgh.pa.us>
To: walther@technowledgy.de
Cc: Bruce Momjian <bruce@momjian.us>
Cc: Thomas Munro <thomas.munro@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>
Cc: Christophe Pettus <xof@thebuild.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: PostgreSQL Bugs <pgsql-bugs@lists.postgresql.org>
Cc: Robert Haas <robertmhaas@gmail.com>
Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded
Date: Tue, 26 Mar 2024 10:35:43 -0400
Message-ID: <2822007.1711463743@sss.pgh.pa.us> (raw)
In-Reply-To: <672a33fb-2ce9-4fcb-8707-c8d6e56c3ed5@technowledgy.de>
References: <ZfrmN4WHuJgD95fw@momjian.us>
<CA+hUKGJzC4rr2Yr=QZyx9W83Wv=TVJHndKF1anjNLNXVUM7TqQ@mail.gmail.com>
<f98cd8de-1c66-491a-8409-e62c09932080@technowledgy.de>
<36690fcf-f0c8-4d60-af49-6a7efa0e2b14@technowledgy.de>
<CA+hUKGJAkTZUa9JGr-zsadaqsN=K0P71t-1L2t2=MQFDMc4GuQ@mail.gmail.com>
<ZfzLsiXbguTDatiZ@momjian.us>
<a2463df1-be45-4a76-b90f-7676d778e7b1@technowledgy.de>
<Zf2JU0_GDdbeBm5j@momjian.us>
<Zf3fnKpHIGpe5mOi@momjian.us>
<2293691d-2adb-4502-b956-73e79dc43c55@technowledgy.de>
<ZgH8GiD0CqYrTPQq@momjian.us>
<2712255.1711408465@sss.pgh.pa.us>
<672a33fb-2ce9-4fcb-8707-c8d6e56c3ed5@technowledgy.de>
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 <tgl@sss.pgh.pa.us>
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
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-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, walther@technowledgy.de, bruce@momjian.us, thomas.munro@gmail.com, peter@eisentraut.org, xof@thebuild.com, andrew@dunslane.net, pgsql-bugs@lists.postgresql.org, robertmhaas@gmail.com
Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded
In-Reply-To: <2822007.1711463743@sss.pgh.pa.us>
* 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