| From: | Christoph Berg <myon(at)debian(dot)org> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Printing backtrace of postgres processes |
| Date: | 2024-02-23 15:39:47 |
| Message-ID: | Zdi8Qy-32rSrhy_S@msg.df7cb.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2024-02-23 15:43:28 | Re: Relation bulk write facility |
| Previous Message | Peter Eisentraut | 2024-02-23 15:26:53 | RangeTblEntry jumble omissions |