On Wed, Dec 11, 2019 at 4:17 AM Fabio Ugo Venchiarutti
<f.venchiarutti@ocado.com> wrote:
> On 10/12/2019 15:06, Tom Lane wrote:
> > =?utf-8?B?0J7Qu9C10LMg0KHQsNC80L7QudC70L7Qsg==?= <splarv@ya.ru> writes:
> >> According to the documentation
> >> https://www.postgresql.org/docs/12/runtime-config-connection.html
> >> A backend must check connection to the client by tcp_keepalive messages. (Config option tcp_keepalives_idle).
> >
> >> But this is don't work if the backend is busy.
> >
> > You're reading something into the documentation that isn't there.
> >
> > The TCP keepalive mechanism is something that the OS does, independently
> > of backend processing. The backend isn't going to notice loss of client
> > connection until it tries to read or write on the connection.
> >
> > If it were free to improve this, we might do so. But it would be
> > very much not free.
>
> At what points does the backend bite the bullet to test the state of
> that file descriptor?
>
> I'd expect select() and poll() to return immediately when keepalive
> probes timeout, so idling clients are covered (and that's the main use
> case); does any other code path go out if its way to ensure that there's
> still a client without actually needing to read()/write()/send()/recv()?
> (obviously at the cost you mentioned)
It has been proposed that busy backends should (optionally)
periodically try to do a MSG_PEEK so they can learn about a client
that has gone away some time before they eventually try to write:
https://www.postgresql.org/message-id/flat/77def86b27e41f0efcba411460e929ae%40postgrespro.ru
More work is needed to move that forward, though.