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)
commitf3f467b8f69b673fb73d15bf5ccd3a2027403d7b
tree9dd4c9798b92607bfdb383168c859f243639cb24
parentcf925936ecc031355cd56fbd392ec3180517a110
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