On Wed, Aug 25, 2021 at 10:22 AM Denis Smirnov <s...@arenadata.io> wrote: > 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?
That is a great question. I think bgworker_die() is extremely dangerous and ought to be removed. I can't see how that can ever be safe. FloatExceptionHandler() is a bit different because in theory the things that could trigger SIGFPE are relatively limited, and in theory we know that those are safe places to ereport(). But I'm not very convinced that this is really true. Among other things, kill -FPE could be executed any time, but even aside from that, I doubt we have exhaustive knowledge of everything in the code that could trigger a floating point exception. -- Robert Haas EDB: http://www.enterprisedb.com
