Thread

1. Hung backends

   Schmidt, Peter <peter.schmidt@prismedia.com> — 2000-11-17T18:38:37Z

   Hi,
   
   I'm new to PostgreSQL and have been tasked with determining the cause of
   hung processes on FreeBSD after the frontend app dies. Eventually we run out
   of connections when hung processes = MAXBACKENDS.
   
   ps -cl -U postgres returns:
   
   UID   PID  PPID CPU PRI NI   VSZ  RSS WCHAN  STAT  TT       TIME COMMAND
     500  1395     1   0   2  0  4040 2380 select Ss    ??    0:01.17 postgres
     500  2255  1395   0   2  0  4384 2984 sbwait I     ??    0:00.01 postgres
     500  2256  1395   0   2  0  4384 2984 sbwait I     ??    0:00.01 postgres
     500  2257  1395   0   2  0  4384 2984 sbwait I     ??    0:00.01 postgres
     500  2258  1395   0   2  0  4384 2984 sbwait I     ??    0:00.01 postgres
     500  2259  1395   0   2  0  4384 2984 sbwait I     ??    0:00.01 postgres
     ...
   
   The java frontend I'm using to test this scenario makes multiple connections
   and crashes(unhandled exception) before disconnecting. This appears to leave
   one "postgres" proccess for each connection. Can anyone point me in the
   right direction?
   SELECT version(); ->  PostgreSQL 7.0.2 on i386-unknown-freebsdelf4.0
   
   Thanks for any advice.
   Peter Schmidt
   
   

2. Re: Hung backends

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-11-23T17:34:47Z

   "Schmidt, Peter" <peter.schmidt@prismedia.com> writes:
   > The java frontend I'm using to test this scenario makes multiple connections
   > and crashes(unhandled exception) before disconnecting. This appears to leave
   > one "postgres" proccess for each connection. Can anyone point me in the
   > right direction?
   > SELECT version(); ->  PostgreSQL 7.0.2 on i386-unknown-freebsdelf4.0
   
   Hm.  I'd definitely recommend updating to 7.0.3 if you are using
   unreliable clients, because 7.0.2 forgets to run its transaction-abort
   routine if the client disconnects mid-transaction, with various
   annoying consequences.  However, that wouldn't lead to the
   above-described symptom.
   
   It looks like the backends don't know that their clients have gone away,
   which would suggest that the kernel is failing to deliver an EOF
   indication on the socket connection.  Are you using TCP connections,
   or Unix sockets?  Is there some other process that could be holding the
   client end of the connection open?
   
   			regards, tom lane