On Wed, Dec 11, 2019 at 4:17 AM Fabio Ugo Venchiarutti <f.venchiaru...@ocado.com> wrote: > On 10/12/2019 15:06, Tom Lane wrote: > > =?utf-8?B?0J7Qu9C10LMg0KHQsNC80L7QudC70L7Qsg==?= <spl...@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.
