From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: zombie connections |
Date: | 2020-04-03 12:57:10 |
Message-ID: | 20200403125710.pnprklk5wb4jis55@nol |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 03, 2020 at 02:40:30PM +0200, Pavel Stehule wrote:
> pá 3. 4. 2020 v 14:30 odesílatel Robert Haas <robertmhaas(at)gmail(dot)com> napsal:
> >
> > Suppose that the server is executing a lengthy query, and the client
> > breaks the connection. The operating system will be aware that the
> > connection is no more, but PostgreSQL doesn't notice, because it's not
> > try to read from or write to the socket. It's not paying attention to
> > the socket at all. In theory, the query could be one that runs for a
> > million years and continue to chew up CPU and I/O, or at the very
> > least a connection slot, essentially forever. That's sad.
> >
> > I don't have a terribly specific idea about how to improve this, but
> > is there some way that we could, at least periodically, check the
> > socket to see whether it's dead? Noticing the demise of the client
> > after a configurable interval (maybe 60s by default?) would be
> > infinitely better than never.
> >
>
> + 1
+1 too, I already saw such behavior.
Maybe the postmaster could send some new PROCSIG SIGUSR1 signal to backends at
a configurable interval and let ProcessInterrupts handle it?
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Knizhnik | 2020-04-03 13:34:17 | Re: zombie connections |
Previous Message | Prabhat Sahu | 2020-04-03 12:43:36 | Re: [Proposal] Global temporary tables |