]> 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)
commit050949877004f003b7d95fddf8f572a32f3a2f70
tree72cc73169580e5ca70f48ec88829f01f5dbeb80e
parent17da9d4c28297fd699cbbda969a9f64c4c09c665
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