From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | f(dot)venchiarutti(at)ocado(dot)com |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Олег Самойлов <splarv(at)ya(dot)ru>, "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: tcp keep alive don't work when the backend is busy |
Date: | 2019-12-11 04:35:55 |
Message-ID: | CA+hUKGLJbWRT_ZpsQwo+ZtH2WCLWiNf1LQ0_Ph4hm1riBSF+Ag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Dec 11, 2019 at 4:17 AM Fabio Ugo Venchiarutti
<f(dot)venchiarutti(at)ocado(dot)com> wrote:
> On 10/12/2019 15:06, Tom Lane wrote:
> > =?utf-8?B?0J7Qu9C10LMg0KHQsNC80L7QudC70L7Qsg==?= <splarv(at)ya(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Shalini | 2019-12-11 05:12:51 | Re: Tuple concurrency issue in large objects |
Previous Message | Tatsuo Ishii | 2019-12-11 00:11:12 | Re: pgpool-II 3.7.5 with ssl |