Re: zombie connections

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?

In response to

Browse pgsql-hackers by date

  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