]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Avoid calling strerror[_r] in PQcancel().
authorTom Lane <tgl@sss.pgh.pa.us>
Mon, 17 Jan 2022 17:52:44 +0000 (12:52 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Mon, 17 Jan 2022 17:52:44 +0000 (12:52 -0500)
commitf27af7b880de97cccd24e37a62692f294bba5bba
tree23735654ab7e3fac4b827c9f5308c96944fb9763
parent90a847e6dcc8fcf8d6f0eaf7b8022153d3b0f184
Avoid calling strerror[_r] in PQcancel().

PQcancel() is supposed to be safe to call from a signal handler,
and indeed psql uses it that way.  All of the library functions
it uses are specified to be async-signal-safe by POSIX ...
except for strerror.  Neither plain strerror nor strerror_r
are considered safe.  When this code was written, back in the
dark ages, we probably figured "oh, strerror will just index
into a constant array of strings" ... but in any locale except C,
that's unlikely to be true.  Probably the reason we've not heard
complaints is that (a) this error-handling code is unlikely to be
reached in normal use, and (b) in many scenarios, localized error
strings would already have been loaded, after which maybe it's
safe to call strerror here.  Still, this is clearly unacceptable.

The best we can do without relying on strerror is to print the
decimal value of errno, so make it do that instead.  (This is
probably not much loss of user-friendliness, given that it is
hard to get a failure here.)

Back-patch to all supported branches.

Discussion: https://postgr.es/m/2937814.1641960929@sss.pgh.pa.us
src/interfaces/libpq/fe-connect.c