Hi,
In the description:
Provide a new optional GUC that can be used to check whether the client
connection has gone away periodically while running very long queries.
I think moving 'periodically' to the vicinity of 'to check' would make the sentence more readable.
+ the operating system, or the
+ <xref linkend="guc-tcp-keepalives-idle"/>,
+ <xref linkend="guc-tcp-keepalives-idle"/> and
The same guc is listed twice. I am not sure if that was intended.
Cheers
On Tue, Mar 23, 2021 at 11:47 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> That leaves the thorny problem Tom mentioned at the top of this
> thread[1]: this socket-level approach can be fooled by an 'X' sitting
> in the socket buffer, if a client that did PQsendQuery() and then
> PQfinish(). Or perhaps even by SSL messages invisible to our protocol
> level. That can surely only be addressed by moving the 'peeking' one
> level up the protocol stack. I've attached a WIP attemp to do that,
> on top of the other patch. Lookahead happens in our receive buffer,
> not the kernel's socket buffer.
After sleeping on this, I'm still not seeing any problem with this
approach. Sanity checks welcome. Of course that function should be
called something like pq_peekmessage() -- done. I think this patch
addresses all critiques leveled at the earlier versions, and I've
tested this with SSL and non-SSL connections, by killing psql while a
query runs, and using a client that calls PQfinish() after starting a
query, and in an earlier version I did yank-the-cable testing, having
set up TCP keepalive to make that last case work.