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

On Fri, Mar 22, 2024 at 11:42:52AM +1300, Thomas Munro wrote:
> On Fri, Mar 22, 2024 at 9:30 AM <walther@technowledgy.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.

Actually, I was thinking the opposite.  Since the musl libc is widely
used, it will be tested, and I don't want to disable process display
updates for such a common platform.

I suggest we use the #ifdef test to continue our existing behavior for
the libraries we know about, like glibc, and use the LD_* process title
truncation hack for libc's we don't recognize.

Attached is a prototype patch which implements this based on previous
patches.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.