From: | Christophe Pettus <xof(at)thebuild(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Andrew Dunstan <andrew(at)dunslane(dot)net>, Wolfgang Walther <walther(at)technowledgy(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Date: | 2024-03-18 09:33:45 |
Message-ID: | E5D4E3AE-C926-48C5-84DC-57E3E9357675@thebuild.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
> On Mar 17, 2024, at 16:20, Thomas Munro <thomas(dot)munro(at)gmail(dot)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 finding libraries... 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 of detecting a libc that passes the other tests but doesn't support any of the existing hacks.
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2024-03-18 13:25:33 | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Previous Message | Amit Kapila | 2024-03-18 09:18:56 | Re: Potential data loss due to race condition during logical replication slot creation |
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2024-03-18 09:41:41 | Re: Refactoring backend fork+exec code |
Previous Message | Bertrand Drouvot | 2024-03-18 09:32:40 | Re: Introduce XID age and inactive timeout based replication slot invalidation |