Re: Strange failure on mamba

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Strange failure on mamba
Date: 2022-11-30 06:55:49
Message-ID: 20221130065549.zkyzodp5pax7etmn@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2022-11-29 22:31:50 -0800, Andres Freund wrote:
> On 2022-11-30 00:55:42 -0500, Tom Lane wrote:
> > Andres Freund <andres(at)anarazel(dot)de> writes:
> > > What libraries is postgres linked against? I don't know whether -z now only
> > > affects the "top-level" dependencies of postgres, or also the dependencies of
> > > shared libraries that haven't been built with -z now. The only dependencies
> > > that I could see being relevant are libintl and openssl.
> >
> > Hmm. mamba is using both --enable-nls and --with-openssl, but
> > I can't see a reason why the postmaster would be interacting with
> > OpenSSL post-startup in test cases that don't use SSL. Perhaps
> > libintl is doing something it shouldn't?
>
> We do call into openssl in postmaster, via RandomCancelKey(). But we should
> have signals masked at that point, so it shouldn't matter.

Openssl does some muckery with signal masks on ppc (and a few others archs,
but not x86), but I don't immediately see it conflicting with our code:

https://github.com/openssl/openssl/blob/master/crypto/ppccap.c#L275

It should also already have been executed by the time we accept connections,
due to the __attribute__ ((constructor)).

I didn't check where netbsd gets libcrypto and whether it does something
different than upstream openssl...

Greetings,

Andres Freund

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2022-11-30 06:56:36 Re: pg_get_constraintdef: Schema qualify foreign tables unless pretty printing is enabled
Previous Message Michael Paquier 2022-11-30 06:55:16 Re: Query Jumbling for CALL and SET utility statements