From: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
---|---|
To: | 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 13:34:17 |
Message-ID: | e99841a2-d219-ad33-f975-93f96440bf93@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 03.04.2020 15:29, Robert Haas wrote:
> Hi,
>
> 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.
>
There was a patch on commitfest addressing this problem:
https://commitfest.postgresql.org/21/1882/
It it currently included in PostgrePro EE, but the author of the patch
is not working in our company any more.
Should we resurrects this patch or there is something wrong with the
proposed approach?
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2020-04-03 13:42:40 | Re: User Interface for WAL usage data |
Previous Message | Julien Rouhaud | 2020-04-03 12:57:10 | Re: zombie connections |