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

From Tom Lane
Subject Re: Regression tests fail with musl libc because libpq.so can't be loaded
Date
Msg-id 782438.1711062167@sss.pgh.pa.us
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>)
Re: Regression tests fail with musl libc because libpq.so can't be loaded  (Andrew Dunstan <andrew@dunslane.net>)
Re: Regression tests fail with musl libc because libpq.so can't be loaded  (walther@technowledgy.de)
List pgsql-bugs
Thomas Munro <thomas.munro@gmail.com> writes:
> 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.

I'm resistant to assuming the postmaster is launched through pg_ctl.
systemd, for example, might well prefer not to do that, not to
mention all the troglodytes still using 1990s launch scripts.

A question that seems worth debating in this thread is how much
updating the process title is even worth nowadays.  It feels like
a hangover from before we had pg_stat_activity and other monitoring
support.  So I don't feel a huge need to support it on musl.
The previously-suggested patch to whitelist glibc and variants,
and otherwise fall back to PS_USE_NONE, seems like it might be
the appropriate amount of effort.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Thomas Munro
Date:
Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded
Next
From: Thomas Munro
Date:
Subject: Re: Regression tests fail with musl libc because libpq.so can't be loaded