> 25 авг. 2021 г., в 19:22, Denis Smirnov <s...@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+zt4byjdvp4sz...@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 - both backtrace 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.

Reply via email to