41–50 of 50 posts
TLS is not async signal safe. But having a dedicated thread whose responsibility is to only send cancel tokens via a TLS connection and is woken up by a posix semaphore seems a small, self contained change that doesn't require any major refactoring.
This doesn't really have anything to do with async signal safety. You could perfectly fine capture the Ctrl+C in psql, stick a notifier byte in a pipe (or use signalfd to begin with) and handle it as a synchronous event in a main loop. You'd still need to establish a new connection purely to bypass buffered data. (or use TCP URG, but that seems generally a poor idea.)
Likely psql doesn't even have a "main loop"; I expect it just blocks on recv() until it gets a response from the server. And on Linux, I think it will automatically restart/resume syscalls that were in progress when a signal fires, so you can't even rely on EINTR to get you out of that recv() so you could check a global flag that you could set in the signal handler.
Although, reading the sigaction() manpage, if you don't specify SA_RESTART, it shouldn't do this? (If they are using signal() and not sigaction(), it might always restart?) But still, not sure why they don't take that route. I imagine it would require much less of a refactor to set a global flag, and then always check it after a recv() fails with EINTR.
Sure, the "right" thing to do is have a global pipe, and instead of blocking in recv(), poll() on it with both the connection socket and the read end of the pipe. And I bet that would require a bit of a refactor. But a global flag is somewhere in the middle...
But who knows; I've never read their source code, so I expect they know what they're talking about when they say it's not a trivial fix.
Earlier quoted context omitted.
This doesn't really have anything to do with async signal safety. You could perfectly fine capture the Ctrl+C in psql, stick a notifier byte in a pipe (or use signalfd to begin with) and handle it as a synchronous event in a main loop. You'd still need to establish a new connection purely to bypass buffered data. (or use TCP URG, but that seems generally a poor idea.)
> This doesn't really have anything to do with async signal safety. TLS not being async signal safe is explicitly called out on the article as the reason the token is sent in clear text. > Handle it as a synchronous event in a main loop Of course of you rearchitect the client there are better solutions. But again, the article mentions that's not planned for now. By comparison, delegating cancellation to a background…
pthread_create() isn't async signal safe, though, so they can't simply move their socket code for the cancellation into another function and call pthread_create() on it. They still have to get the main thread to stop doing what its doing (usually via the pipe trick) in order to create the thread, which could easily be a big refactor.
> Edit: the article mentions that there is a refactor in the works to implement cancel over tls [1]. Turns out that they decided to use a thread (with a pipe for signaling).
Seems odd to me to bother. If you have to do the pipe thing, why not just do the new connection for cancellation in the main thread once it sees the data on the pipe? I guess that way they can return control of the CLI to the user while they cancel in the background, rather than blocking the user while the cancellation is going on. But as a user, I kinda would like to know that the query I just cancelled actually got cancelled, a property that the old code has, but the new code won't.
(Presumably the new code can print a warning if cancellation fails, but it could take a long time to fail, and in the meantime the user has moved on.)
Earlier quoted context omitted.
This doesn't really have anything to do with async signal safety. You could perfectly fine capture the Ctrl+C in psql, stick a notifier byte in a pipe (or use signalfd to begin with) and handle it as a synchronous event in a main loop. You'd still need to establish a new connection purely to bypass buffered data. (or use TCP URG, but that seems generally a poor idea.)
I believe the suggestion is to have a TLS endpoint in the server, which demultiplexes the incoming CancelRequest and signals to the corresponding worker process via shared memory
Earlier quoted context omitted.
I believe the suggestion is to have a TLS endpoint in the server, which demultiplexes the incoming CancelRequest and signals to the corresponding worker process via shared memory
The problem isn't on the server; the server already knows how to cancel things, and already supports cancellation over TLS. It's just that psql doesn't use it, due to the need for a refactor to make that work. Other psql-like frontends do already use it, as the article points out.
Earlier quoted context omitted.
> This doesn't really have anything to do with async signal safety. TLS not being async signal safe is explicitly called out on the article as the reason the token is sent in clear text. > Handle it as a synchronous event in a main loop Of course of you rearchitect the client there are better solutions. But again, the article mentions that's not planned for now. By comparison, delegating cancellation to a background…
> By comparison, delegating cancellation to a background background thread can be done non-intrusively. In principe no code outside the cancel path need changing. pthread_create() isn't async signal safe, though, so they can't simply move their socket code for the cancellation into another function and call pthread_create() on it. They still have to get the main thread to stop doing what its doing (usually via the pi…
Earlier quoted context omitted.
offtopic, but it's interesting how large of a discrepancy there is between the length of your comment and how much time i'd have to spend explaining background info to a non-programmer to get them to understand why this is funny
why is it funny? it seems like a sincere question
And as GP wrote, it would take a substantial amount of time to explain to a normie (infinite I'd say, but let's not despair).
Earlier quoted context omitted.
> By comparison, delegating cancellation to a background background thread can be done non-intrusively. In principe no code outside the cancel path need changing. pthread_create() isn't async signal safe, though, so they can't simply move their socket code for the cancellation into another function and call pthread_create() on it. They still have to get the main thread to stop doing what its doing (usually via the pi…
Of course you don't spawn a thread from the signal handler. You start it first thing in main and park it waiting for a wakeup.
That is a much simpler change than refactoring the main thread to poll on several FDs instead of just blocking in recv().
[flagged]
cancel key is arbitrary sized https://www.postgresql.org/docs/current/protocol-message-for... / BackendKeyData I'm fairly certain that this cancellation approach has nothing to do with UNIX networking assumptions, and everything to do with the connection/process model of PostgreSQL. Creating a connection => starting a process and passing the accepted socket to it (so in-band cancel would have to go directy to the bac…
Earlier quoted context omitted.
is sed s/—/--/ the new meta
I have used "--" as a lazy-man's emdash for decades at this point. Once I heard that people started assuming text that uses emdashes was written by an LLM I got worried that people were going to think that I'm an LLM, but then I realized the LLMs use the real unicode emdash character, while I just use two regular ASCII-zone hyphens. Whew. (Also I just learned that ASCII 0x2d/unicode U+002D is more properly called a "…
this is maybe the fifth time i've seen this happen on hn in the last few weeks