From: | Denis Smirnov <sd(at)arenadata(dot)io> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Async-unsafe functions in signal handlers |
Date: | 2021-08-25 14:22:08 |
Message-ID: | 7E3165DE-601D-4930-A85F-35BD6318E1C2@arenadata.io |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 - 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?
Best regards,
Denis Smirnov | Developer
sd(at)arenadata(dot)io
Arenadata | Godovikova 9-17, Moscow 129085 Russia
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2021-08-25 14:35:33 | Re: Mark all GUC variable as PGDLLIMPORT |
Previous Message | Robert Haas | 2021-08-25 14:08:54 | Re: Postgres perl module namespace |