Re: Printing backtrace of postgres processes

Поиск
Список
Период
Сортировка
От Christoph Berg
Тема Re: Printing backtrace of postgres processes
Дата
Msg-id Zdi8Qy-32rSrhy_S@msg.df7cb.de
обсуждение исходный текст
Ответ на Re: Printing backtrace of postgres processes  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Printing backtrace of postgres processes  (Michael Paquier <michael@paquier.xyz>)
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: RangeTblEntry jumble omissions
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Relation bulk write facility