diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2022-01-17 13:30:04 -0500 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2022-01-17 13:30:04 -0500 |
commit | d18ec312f9f36c220aa1a1497d3173729c862d66 (patch) | |
tree | aae9e972d10b69e54f481338453cdd86090fa613 /src/common/file_utils.c | |
parent | f27af7b880de97cccd24e37a62692f294bba5bba (diff) | |
download | postgresql-d18ec312f9f36c220aa1a1497d3173729c862d66.tar.gz postgresql-d18ec312f9f36c220aa1a1497d3173729c862d66.zip |
Avoid calling gettext() in signal handlers.
It seems highly unlikely that gettext() can be relied on to be
async-signal-safe. psql used to understand that, but someone got
it wrong long ago in the src/bin/scripts/ version of handle_sigint,
and then the bad idea was perpetuated when those two versions were
unified into src/fe_utils/cancel.c.
I'm unsure why there have not been field complaints about this
... maybe gettext() is signal-safe once it's translated at least
one message? But we have no business assuming any such thing.
In cancel.c (v13 and up), I preserved our ability to localize
"Cancel request sent" messages by invoking gettext() before
the signal handler is set up. In earlier branches I just made
src/bin/scripts/ not localize those messages, as psql did then.
(Just for extra unsafety, the src/bin/scripts/ version was
invoking fprintf() from a signal handler. Sigh.)
Noted while fixing signal-safety issues in PQcancel() itself.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/2937814.1641960929@sss.pgh.pa.us
Diffstat (limited to 'src/common/file_utils.c')
0 files changed, 0 insertions, 0 deletions