[flagged]
is sed s/—/--/ the new meta
The way CTRL-C in Postgres CLI cancels queries is incredibly hack-y
21–30 of 50 posts
Re: The way CTRL-C in Postgres CLI cancels queries is incredibly hack-y
#22Re: The way CTRL-C in Postgres CLI cancels queries is incredibly hack-y
#23Re: The way CTRL-C in Postgres CLI cancels queries is incredibly hack-y
#24[flagged]
Doesn't it also make sense in the context of modern networking assumptions? I've never had to connect to PostGres in an adversarial environment. I've been at work or at home and I connected to PostGres instances owned by me or my employer. If I tried to connect to my work instance from a coffee shop, the first thing I'd do would be to log in to a VPN. That's your multiplexed protocol layer right there: the security h…
>I've never had to connect to PostGres in an adversarial environment.
heroku's postgres database service still exposes itself on the public internet.
Re: The way CTRL-C in Postgres CLI cancels queries is incredibly hack-y
#25[flagged]
Doesn't it also make sense in the context of modern networking assumptions? I've never had to connect to PostGres in an adversarial environment. I've been at work or at home and I connected to PostGres instances owned by me or my employer. If I tried to connect to my work instance from a coffee shop, the first thing I'd do would be to log in to a VPN. That's your multiplexed protocol layer right there: the security h…
Zero trust security which is becoming increasingly common is based on removing the internal / external network dichotomy entirely. Everything should be assumed to be reachable from the open internet (so SSO, OIDC everywhere.)
Re: The way CTRL-C in Postgres CLI cancels queries is incredibly hack-y
#26Re: The way CTRL-C in Postgres CLI cancels queries is incredibly hack-y
#27Re: The way CTRL-C in Postgres CLI cancels queries is incredibly hack-y
#28In general I love postgres. There are to problems with postgresql in my book: the protocol (proto3) and no great way to directly query using a different language.
The protocol has no direct in-protocol cancellation, like TDS has. TDS does this by making a framed protocol, at the application protocol level it can cancel queries. It has two variants (text and binary) and can cause fragmentation, and at the query and protocol level only supports positional parameters, no named parameters.
One a query is on the server, it doesn't support directly acting on a language mode. I don't want to go into SQL mode and create a PL/SQL proc, I just want direct PL/SQL. Can't (really) do that well. Directly returning multiple result sets (eg for a matrxi, separate rows, columns, and fields) or related queries in a single round trip is technically possible, but hard to do. So frustrating.
Re: The way CTRL-C in Postgres CLI cancels queries is incredibly hack-y
#29TCP has an "urgent data" feature that might have been used for this kind of thing, used for Ctrl-C in telnet, etc. It can be used to bypass any pending send buffer and received by the server ahead of any unread data.
Just googling it now and TCP urgent data seems to be a mess.
Reading the original RFC 793 it's clear that the intention was never for this to be OOB data, but to inform the receiver that they should consume as much data as possible and minimally process it / buffer it locally until they have read up to the urgent data.
However, the way it was historically implemented as OOB data seems to be significantly more useful - you could send flow control messaging to be processed immediately even if you knew the receiving side had a lot data to consume before it'd see an inline message.
It seems nowadays the advice is just to not use urgent data at all.
Re: The way CTRL-C in Postgres CLI cancels queries is incredibly hack-y
#30From the title I was hoping for this being hacky on the server application side, like how it aborts and clears the memory for a running query. Still an interesting read. Just wondering, why can't the TCP connection of the query not be used to send a cancellation request? Why does it have the be out of band?
Because Postgres is a very old codebase and was written in a style that assumes there are no threads, and thus there's nothing to listen for a cancellation packet whilst work is getting done. A lot of UNIXes had very poor support for threads for a long time and so this kind of multi-process architecture is common in old codebases. The TCP URG bit came out of this kind of problem. It triggers a SIGURG signal on UNIX w…
> how many web servers abort request processing if the connection drops?
I don't think I have ever seen a published web service which error log wasn't full of broken pipe messages. So, AFAIK, all.