aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist/gistxlog.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2022-01-17 13:30:04 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2022-01-17 13:30:04 -0500
commit4e8726566e4d7c0e712d16c0dc7a27d212ece090 (patch)
tree9fcbce1d517fef0879e41a4df219570c55cc13fc /src/backend/access/gist/gistxlog.c
parent050949877004f003b7d95fddf8f572a32f3a2f70 (diff)
downloadpostgresql-4e8726566e4d7c0e712d16c0dc7a27d212ece090.tar.gz
postgresql-4e8726566e4d7c0e712d16c0dc7a27d212ece090.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/backend/access/gist/gistxlog.c')
0 files changed, 0 insertions, 0 deletions