From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | walther(at)technowledgy(dot)de |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Christophe Pettus <xof(at)thebuild(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL Bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us> |
Subject: | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Date: | 2024-03-21 22:42:52 |
Message-ID: | CA+hUKGJAkTZUa9JGr-zsadaqsN=K0P71t-1L2t2=MQFDMc4GuQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
On Fri, Mar 22, 2024 at 9:30 AM <walther(at)technowledgy(dot)de> wrote:
> > 4. The upstream (musl) suggestion of which I sent a PoC was to "exec
> > yourself with a bigger argv".
>
> We could do this in HEAD now ...
Just a thought: if we want to go this way, do we need a new exec call?
We already control the initial exec in pg_ctl.c.
> > Could we even use the exec-approach as the fallback in all other cases
> > except BSDs and Windows and get rid of PS_USE_NONE?
>
> ... and then remove PS_USE_NONE at the beginning of the v18 cycle.
>
> This would give a bit more time for those "other systems", which were
> previously falling back PS_USE_NONE and would then clobber argv, too.
RIght. It's unspecified by POSIX whether ps shows changes to those
strings (and there are systems that don't), but it can't hurt to do so
anyway, and it'd be better than having a PS_USE_NONE code path that is
untested. I dimly recall that it turned out that PS_USE_NONE was
actually broken for a while without anyone noticing.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-03-21 23:02:47 | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
Previous Message | walther | 2024-03-21 20:30:00 | Re: Regression tests fail with musl libc because libpq.so can't be loaded |
From | Date | Subject | |
---|---|---|---|
Next Message | Matthias van de Meent | 2024-03-21 22:42:58 | Re: DRAFT: Pass sk_attno to consistent function |
Previous Message | David G. Johnston | 2024-03-21 22:31:37 | Re: documentation structure |