The way CTRL-C in Postgres CLI cancels queries is incredibly hack-y
27 points by runxiyu
27 points by runxiyu
What is most fascinating is reading along going "yep, yep, I see how that is not optimal..."
At the same time recognizing the engineering tradeoffs that led to this pattern of behavior. Signal safe is hard. Interrupting a TCP connection Now (tm) is hard. Identitying exactly which query is running and for which client is hard.
All of that comes together to make a system that has warts but by golly it works.
The main point of the article is that it’s insecure; the warts are less important except that they are why it’s hard to make it secure.
Interrupting a TCP connection Now (tm) is hard
Just copy telnet :-) But Postgres allows connections over unix domain sockets and TLS and other things that don’t have TCP urgent data, so copying telnet isn’t an option. But that isn’t really the problem: after all, ssh can deliver interrupts without TCP urgent data.
On the server, ssh and telnet rely on separate connection-handling and application processes, so the daemon can signal the application when it receives an interrupt instruction over the socket. Postgres has only one process per connection, and it isn’t multithreaded so it doesn’t have separate connection-handling and query-running threads. The query runner doesn’t do periodic cancellation checks, so to cancel a query you have to send a signal to the process. To send a signal from a remote client, you need another process on the server and therefore another connection.
Took this title from HN as the original “Ctrl-C in psql gives me the heebie-jeebies” didn’t tell me much.
Hitting ^C from a Postgres-in-Podman shell would cause the container to crash and restart until recent-ish for me.