Re: Async-unsafe functions in signal handlers - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: Async-unsafe functions in signal handlers
Date
Msg-id 9C723B8A-258C-47BF-A18B-231008DA2452@yandex-team.ru
Whole thread Raw
In response to Async-unsafe functions in signal handlers  (Denis Smirnov <sd@arenadata.io>)
Responses Re: Async-unsafe functions in signal handlers  (Denis Smirnov <sd@arenadata.io>)
List pgsql-hackers

> 25 авг. 2021 г., в 19:22, Denis Smirnov <sd@arenadata.io> написал(а):
>
> I am going to refactor Greenplum backtraces for error messages and want to make it more compatible with PostgreSQL
code.Backtraces in PostgreSQL were introduced by 71a8a4f6e36547bb060dbcc961ea9b57420f7190 commit (original discussion
https://www.postgresql.org/message-id/CAMsr+YGL+yfWE=JvbUbnpWtrRZNey7hJ07+zT4bYJdVp4Szdrg@mail.gmail.com) and rely on
backtrace()and backtrace_symbols() functions. They are used inside errfinish() that is wrapped by ereport() macros.
ereport()is invoked inside bgworker_die() and FloatExceptionHandler() signal handlers. I am confused with this fact -
bothbacktrace functions are async-unsafe: backtrace_symbols() - always, backtrace() - only for the first call due to
dlopen.I wonder why does PostgreSQL use async-unsafe functions in signal handlers? 

In my view GUC backtrace_functions is expected to be used for debug purposes. Not for enabling on production server for
bgworker_die()or FloatExceptionHandler(). 
Are there any way to call backtrace_symbols() without touching backtrace_functions?

Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Skipping logical replication transactions on subscriber side
Next
From: "kuroda.hayato@fujitsu.com"
Date:
Subject: RE: Allow escape in application_name (was: [postgres_fdw] add local pid to fallback_application_name)