Hope you don't mind if I disagree. Most OS's that have a tcp/ip layer also have a parameter therein called
tcp_keep_alive. They also set this parameter to infinity. The purpose of tcp_keep_alive is to have the OS kernel
periodicallyverify that all tcp/ip connections it is managing are still functioning every so often. Basically the OS
sendsa probe packet down the line to the to the client machine. If it bounces back the connection is dead & the OS can
dowhat it has to, which will then notify postmaster just like you manually did. I'd contact your OS vendor for
informationof what tcp_keep_alive is set to by default and how you can change it.
Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-----Original Message-----
From: Jeff [mailto:threshar@torgo.978.org]
Sent: Friday, January 30, 2004 10:18 AM
To: Mark Harrison
Cc: pgsql-admin@postgresql.org
Subject: Re: [ADMIN] hung postmaster when client machine dies?
On Thu, 29 Jan 2004 17:00:27 -0800
Mark Harrison <mh@pixar.com> wrote:
> We observed that there was postmaster connected to the ip address
> of the downed machine with an "in transaction" status. Killing
> that processes unblocked the other processes.
>
> Is this expected behavior? Was postgres simply waiting for
> a failure from the TCP/IP layer?
>
When a machine simply "goes away" (crashed, unplugged) no packets are
sent indicating the socket has closed so PG doesn't know the socket is
closed and cannot rollback the transaction. (This is true of any
tcp-based protocol).
If that connection had a transaction open it'll likely have rows locked.
Killing PG caused it to rollback that transaction freeing those locks.
Eventually PG would have found out the socket was dead. Most likely if
it tried to write to it.
--
Jeff Trout <jeff@jefftrout.com>
http://www.jefftrout.com/
http://www.stuarthamm.net/
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
