Thread

Don't use the deprecated and insecure PQcancel in our frontend tools anymore

Jelte Fennema-Nio <postgres@jeltef.nl> — 2025-12-14T14:40:25Z

A bunch of frontend tools, including psql, still used PQcancel to send
cancel requests to the server. That function is insecure, because it
does not use encryption to send the cancel request. This starts using
the new cancellation APIs (introduced in 61461a300) for all these
frontend tools. These APIs use the same encryption settings as the
connection that's being cancelled. Since these APIs are not signal-safe
this required a refactor to not send the cancel request in a signal
handler anymore, but instead using a dedicated thread. Similar logic was
already used for Windows anyway, so this also has the benefit that it
makes the cancel logic more uniform across our supported platforms.

Because this is fixing a security issue, it would be nice if we could
backport it. I'm not sure that's realistic though, given the
size/complexity of the change. I'm curious what others think about that.
To be clear, I'm only really talking about backporting to PG17 and PG18
because those contain the new cancellation APIs in libpq. Backporting
to even older versions would also require backporting the new
cancellation APIs in libpq, which seems like a no-go.

A possible follow up improvement to pg_dump would be to use threads for
its parallel workers on UNIX as well. Then the Windows and Unix
implementations would get even more aligned. I started looking into
that, but that quickly became quite a big refactor, touching a lot of
code unrelated to cancellation. So it seems better to do that in a
separate follow-on patch if people are interested.