Re: Add client connection check during the execution of the query

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(dot)munro(at)gmail(dot)com> wrote:

> On Tue, Mar 23, 2021 at 11:47 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)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.
>