Re: Async-unsafe functions in signal handlers

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Denis Smirnov <sd(at)arenadata(dot)io>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Async-unsafe functions in signal handlers
Date: 2021-08-26 05:52:44
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> 25 авг. 2021 г., в 19:22, Denis Smirnov <sd(at)arenadata(dot)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 ) 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.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message 2021-08-26 06:00:27 RE: Allow escape in application_name (was: [postgres_fdw] add local pid to fallback_application_name)
Previous Message 2021-08-26 05:49:36 RE: Skipping logical replication transactions on subscriber side