Postgres Pro
Downloads
Home   >   mailing lists

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

From Bruce Momjian
Subject Re: Regression tests fail with musl libc because libpq.so can't be loaded
Date
Msg-id Zf2JU0_GDdbeBm5j@momjian.us
Whole thread Raw
In response to Re: Regression tests fail with musl libc because libpq.so can't be loaded  (walther@technowledgy.de)
Responses Re: Regression tests fail with musl libc because libpq.so can't be loaded  (Bruce Momjian <bruce@momjian.us>)
List pgsql-bugs
Tree view 
On Fri, Mar 22, 2024 at 09:33:38AM +0100, walther@technowledgy.de wrote:
> Bruce Momjian:
> > 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.
> 
> The condition to check for linux/glibc in your patch is slightly off:
> 
>   #if ! defined(__linux__) || (! defined(__GLIBC__) && defined(__UCLIBC__ ))
> 
> should be
> 
>   #if defined(__linux__) && ! (defined(__GLIBC__) || defined(__UCLIBC__ ))
> 
> With the latter, it passes tests with musl.

Yes, my logic was wrong. Not sure what I was thinking, frankly.

I am not a big fan of negating a complex conditional, but would rather
pass the negation into the conditional, new patch attached.

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

  Only you can decide what is important to you.
Attachment

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #18404: Select from pg_stat_activity in a plpgsql block can lead to a global locking issue
Next
From: Janne Annala
Date:
Subject: NEW.* and OLD.* inside trigger function don't seem to contain recently added columns