Re: Freeing Connections - Mailing list pgsql-admin

From Ross J. Reedstrom
Subject Re: Freeing Connections
Date
Msg-id 20011018221531.A15435@rice.edu
Whole thread Raw
In response to Re: Freeing Connections  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-admin
On Thu, Oct 18, 2001 at 01:55:33PM -0400, Tom Lane wrote:
> Andrew Hill <list@fornax.net> writes:
> > Normally, 32 connections is heaps for what I need. However, I often get
> > connections that seem to be doing nothing. For example:
>
> > [bash]
> >   \_ postmaster -i -D/var/pgsql/data -N 32 -B 64
> >   \_ [postmaster]
> >   \_ /var/pgsql/bin/postgres 202.174.32.67 postgres anb idle
> >   \_ /var/pgsql/bin/postgres 202.174.32.68 postgres anb idle
> >   \_ [postmaster]
> >   \_ /var/pgsql/bin/postgres 203.34.190.137 postgres bmf idle
> >   \_ [postmaster]
> >   \_ [postmaster]
> >   \_ [postmaster]
> >   \_ [postmaster]
> >   \_ /var/pgsql/bin/postgres 202.174.32.8 radius bmf idle
>
> Curious.  Can you attach to some of the unidentified processes with
> a debugger, and get a stack traceback from 'em?  Offhand I can't
> think of a reason for 7.0 to have any subprocesses that haven't
> changed their PS display.  It would help to know what they are doing.

Andrew doesn't mention his platform, but if it's linux, those could just
be swapped out processes: since the execution state gets swapped, the
kernel only has minimal info about the process, including the original
name. I'm guessing that his PHP setup is configured for persistent
connections with MAX_CON >32 and isn't reusing connections properly.
ISTR some vesion of PHP with exactly that bug. Should be in the mailing
list archives.

Ross

pgsql-admin by date:

Previous
From: Brian McCane
Date:
Subject: Re: Please help - tks
Next
From: Andrew Hill
Date:
Subject: Re: Freeing Connections