Re: Printing backtrace of postgres processes

Поиск
Список
Период
Сортировка
От Ashutosh Bapat
Тема Re: Printing backtrace of postgres processes
Дата
Msg-id CAExHW5uN3BJmsJzXDtcaooFgRkUeMs0wpprUwmY1pWZZ4ndv4A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Printing backtrace of postgres processes  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Printing backtrace of postgres processes  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Список pgsql-hackers
On Sat, Feb 10, 2024 at 5:36 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Feb 09, 2024 at 02:27:26PM +0530, Ashutosh Bapat wrote:
> > On Fri, Feb 9, 2024 at 2:18 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> >> Hmm, but the backtrace() manpage says
> >>
> >>        •  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
>
> So I really question whether it is a good idea to assume if this will
> always be safe depending on the version of libgcc dealt with,
> increasing the impact area.  Perhaps that's worrying too much, but it
> looks like one of these things where we'd better be really careful.

I agree. We don't want a call to backtrace printing mechanism to make
things worse.

>
> > We defer actual action triggered by a signal till CHECK_FOR_INTERRUPTS
> > is called. I understand that we can't do that here since we want to
> > capture the backtrace at that moment and can't wait till next CFI. But
> > printing the backend can surely wait till next CFI right?
>
> Delaying the call of backtrace() to happen during a CFI() would be
> safe, yes, and writing data to stderr would not really be an issue as
> at least the data would be sent somewhere.  That's less useful, but
> we do that for memory contexts.

Memory contexts do not change more or less till next CFI, but stack
traces do. So I am not sure whether it is desirable to wait to capture
backtrace till next CFI. Given that the user can not time a call to
pg_log_backend() exactly, so whether it captures the backtrace exactly
at when interrupt happens or at the next CFI may not matter much in
practice.

--
Best Wishes,
Ashutosh Bapat



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: GUC-ify walsender MAX_SEND_SIZE constant
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: Add semi-join pushdown to postgres_fdw