Date: Fri, 23 Feb 2024 16:39:47 +0100
From: Christoph Berg <myon@debian.org>
To: Michael Paquier <michael@paquier.xyz>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
	vignesh C <vignesh21@gmail.com>,
	torikoshia <torikoshia@oss.nttdata.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Printing backtrace of postgres processes
Message-ID: <Zdi8Qy-32rSrhy_S@msg.df7cb.de>
References: <ZcXeuOl9qy7YA9RH@paquier.xyz>
 <202402090848.j6evnpunbehe@alvherre.pgsql>
 <CAExHW5ugP_fAXtZhyES4zW5OtYn8J5e=eDZbSCCVM2ekASQRSg@mail.gmail.com>
 <Zca-C0rND4V0ZWI6@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <Zca-C0rND4V0ZWI6@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/Zdi8Qy-32rSrhy_S%40msg.df7cb.de>
Precedence: bulk

Re: Michael Paquier
> >>        •  backtrace() and backtrace_symbols_fd() don't call malloc()  explic‐
> >>           itly,  but  they  are part of libgcc, which gets loaded dynamically
> >>           when first used.  Dynamic loading usually triggers a call  to  mal‐
> >>           loc(3).   If  you  need certain calls to these two functions to not
> >>           allocate memory (in signal handlers, for example), you need to make
> >>           sure libgcc is loaded beforehand.
> >>
> >> and the patch ensures that libgcc is loaded by calling a dummy
> >> backtrace() at the start of the process.
> 
> FWIW, anything I am reading about the matter freaks me out, including
> the dlopen() part in all the backends:
> https://www.gnu.org/software/libc/manual/html_node/Backtraces.html

I'd be concerned about the cost of doing that as part of the startup
of every single backend process. Shouldn't this rather be done within
the postmaster so it's automatically inherited by forked backends?
(EXEC_BACKEND systems probably don't have libgcc I guess.)

Christoph