From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Lonni J Friedman <netllama(at)gmail(dot)com> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: total number of concurrent connections |
Date: | 2009-07-28 02:02:24 |
Message-ID: | 6370.1248746544@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
Lonni J Friedman <netllama(at)gmail(dot)com> writes:
> On Mon, Jul 27, 2009 at 4:31 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> What are you doing to "terminate" these remote connections? What it
>> sounds like is the connected server process isn't being told about the
>> termination, and so it sits there waiting for input that will never
>> come.
> Normally, just quitting from psql, but as part of today's experiment I
> rebooted the system that the table claimed was still connected. The
> server is running Linux with a reasonably recent 2.6.x kernel.
Hm, but what's the client-side OS? A reasonable OS should send a
connection close notification (TCP RST) when the psql process dies,
even if you managed to kill it in a way that prevented psql from
closing the connection for itself. However, if that didn't happen
for some reason, reboot would not make things better. It would just
guarantee that the OS no longer had any memory of the connection either.
It still sounds like your problems are fundamentally network-level
problems and not Postgres problems... but it's hard to tell from
here whether it's client-side software or network infrastructure
doing it to you.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Lonni J Friedman | 2009-07-28 02:17:22 | Re: total number of concurrent connections |
Previous Message | Lonni J Friedman | 2009-07-27 23:37:15 | Re: total number of concurrent connections |