Re: Printing backtrace of postgres processes - Mailing list pgsql-hackers

From Christoph Berg
Subject Re: Printing backtrace of postgres processes
Date
Msg-id Zdi8Qy-32rSrhy_S@msg.df7cb.de
Whole thread Raw
In response to Re: Printing backtrace of postgres processes  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Printing backtrace of postgres processes  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: RangeTblEntry jumble omissions
Next
From: Heikki Linnakangas
Date:
Subject: Re: Relation bulk write facility