From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Francisco Reyes <lists(at)natserv(dot)com> |
Cc: | pgsql General List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Troublesome handling of dropped connection |
Date: | 2001-11-26 19:32:04 |
Message-ID: | 13668.1006803124@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Francisco Reyes <lists(at)natserv(dot)com> writes:
> I had connected to a Postgresql database, running 7.1.3 on FreeBSD,
> machine through ssh/psql. My machine crashed.
> Upon restart of my machine I recconected to the database machine, again
> ssh to the machine and then run psql.
Did you look to see whether your old session had disconnected or not?
> The table I was loading data to at the time of the disconnection was
> unresponsive.
It sounds like your new session was waiting around for the old session
to complete a transaction and release locks.
Unfortunately, if your old session was not in the midst of
sending/receiving data at the time of the crash, it may take quite a
while (an hour or two) before the TCP code notices that the connection's
been lost. The backend will just sit there patiently until the
connection times out. There is not a lot we can do about this; the
long timeout is mandated by the TCP specs, and the code involved is
kernel code not Postgres code anyway.
You could have zapped the backend more cleanly by sending it a SIGINT.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Francisco Reyes | 2001-11-26 19:34:23 | Re: Strange performance issue |
Previous Message | Jim Buttafuoco | 2001-11-26 19:27:05 | Re: pl/perl won't build under 7.1.3 |