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

From Denis Smirnov
Subject Async-unsafe functions in signal handlers
Date
Msg-id 7E3165DE-601D-4930-A85F-35BD6318E1C2@arenadata.io
Whole thread Raw
Responses Re: Async-unsafe functions in signal handlers  (Andrey Borodin <x4mmm@yandex-team.ru>)
Re: Async-unsafe functions in signal handlers  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Hello all,

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? 

Best regards,
Denis Smirnov | Developer
sd@arenadata.io
Arenadata | Godovikova 9-17, Moscow 129085 Russia




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Postgres perl module namespace
Next
From: Magnus Hagander
Date:
Subject: Re: Mark all GUC variable as PGDLLIMPORT