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 2:54 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > On Tue, Mar 23, 2021 at 11:47 PM Thomas Munro <thomas.mu...@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. >
