"Arthur M. Kang" <arthur@levelogic.com> writes:
> If a postgres connection dies without implicitly disconnecting from the
> database, it seems that the backend processes hangs around
> indefinitely. Does anyone know of a way to get around this??
This sounds like a bug in either your webserver or the underlying
kernel: the postgres backend isn't getting notified that the connection
has been closed. Do you still see the connections as "established"
in netstat?
We did recently change the backend to set TCP "keepalive" mode, so
that the kernel will actively probe for a still-alive far end after a
sufficiently long idle period. But I think the keepalive timeout is
of the order of half an hour, so it might be too long for your tastes.
Not sure it's relevant here anyway; keepalive should only matter if
the far end has suffered either a kernel crash or loss of network
connectivity.
Anyway, the short answer is that the backend shuts down when the kernel
tells it the connection to the client is no longer open. You need to be
looking at TCP connection management issues if the client seems to be
able to quit without provoking a connection closure.
> I'm using Postgres 7.0.2 and ApacheDBI to connected. If I start the
> web server with 10 servers, there is immediately 10 postgres processes.
> If I HUP the web server, there become 20 postgres processes.
Offhand I would guess that Apache forgets to close its outgoing TCP
connections when you HUP it... check with netstat or lsof or something
like that.
regards, tom lane
