Re: Regression tests fail with musl libc because libpq.so can't be loaded - Mailing list pgsql-bugs

From Christophe Pettus
Subject Re: Regression tests fail with musl libc because libpq.so can't be loaded
Date
Msg-id E5D4E3AE-C926-48C5-84DC-57E3E9357675@thebuild.com
Whole thread Raw
In response to Re: Regression tests fail with musl libc because libpq.so can't be loaded  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Regression tests fail with musl libc because libpq.so can't be loaded  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-bugs

> On Mar 17, 2024, at 16:20, Thomas Munro <thomas.munro@gmail.com> wrote:
>
> We'd
> still feel free to clobber the memory up to that point (rather than
> limiting ourselves to the argv space, another more conservative choice
> that might truncate a few PS display messages, or maybe not given the
> typical postmaster arguments, maye that'd work out OK), and we'd still
> copy the environment to somewhere new, but anything like "LD_XXX" that
> the runtime linker might have stashed a pointer to would remain valid.
> /me runs away and hides

It doesn't lack for bravery!  (And I have to just comment that the linker storing pointers into that space as a way of
findinglibraries... well, that doesn't get them the moral high ground for nasty hacks.) 

I'm comfortable with "if you are using musl, you don't get the ps messages" as a first solution, if we can find a way
ofdetecting a libc that passes the other tests but doesn't support any of the existing hacks. 


pgsql-bugs by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Potential data loss due to race condition during logical replication slot creation
Next
From: Thomas Munro
Date:
Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded