From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Shawn <shamccoy(at)amazon(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: An unkillable connection caused replication delay on my replica |
Date: | 2016-06-29 18:39:26 |
Message-ID: | 20160629183926.GA125026@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Shawn wrote:
> Unfortunately...no. I have been trying to repro this scenario. Is there a
> specific way to make a Python connection where this is possible?
>
> My end game, if this is not something that can be fixed on the Postgres
> side, is to come up with a way to automatically cause the connection to drop
> (iptables, something else...etc).
Well. I was toying with a server a few days ago that had two processes
with queries "running" for eight days, but the client had long since
disconnected -- but the TCP keepalives didn't fire, because the kernel
was stuck trying to get free memory for something but the outgoing
network buffer was full so nothing was happening. That looked like a
kernel bug to me, and I don't think iptables would help you there.
Signalling the Postgres process in the normal way didn't do anything, as
they were stuck in the kernel.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-06-29 19:06:35 | Re: Re: Should phraseto_tsquery('simple', 'blue blue') @@ to_tsvector('simple', 'blue') be true ? |
Previous Message | Andres Freund | 2016-06-29 18:32:54 | Re: Improving executor performance |