Stale Process

Started by Terence Leungover 23 years ago4 messagesgeneral
Jump to latest
#1Terence Leung
tcmleung@yahoo.com

Dear sir,
I built Apache, PHP-PostgreSql 7.1 web server in Linux
Redhat 7.0.
I always check the process by 'ps -aux' and always
found the stale postmaster processes:

postgres 9212 0.0 2.1 6136 2408 ? S
Nov09 0:02 postgres: nobody newmy3qdb [local] idle
postgres 10617 0.0 2.4 5628 2740 ? S
Nov09 0:02 postgres: nobody newmy3qdb [local] idle

The processes would not disappear if I don't kill the
processess.
I only use 'pg_connect' but never use
'pg_pconnect'(permanent connection), so why does it
happen and how to solve the problem so that the stale
process can automatically disappear?

=====
Yours sincerely,
Leung Chun Man, Terence

Mobile: (852) 9273 9176
Homepage: http://tcmleung.uhome.net ,
http://www.dynamicdrive.com/dynamicindex4/filter/index.htm

__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2

#2Doug McNaught
doug@mcnaught.org
In reply to: Terence Leung (#1)
Re: Stale Process

Terence Leung <tcmleung@yahoo.com> writes:

Dear sir,
I built Apache, PHP-PostgreSql 7.1 web server in Linux
Redhat 7.0.
I always check the process by 'ps -aux' and always
found the stale postmaster processes:

It's most likely that PHP is keeping the connections open for some
reason. The 'postgres' processes are in S (sleep) state, which
indicates that their socket is still being held open by the client
end. So it's probably not a Postgres problem... I find it entirely
unsurprising that PHP might be buggy. ;)

-Doug

#3scott.marlowe
scott.marlowe@ihs.com
In reply to: Doug McNaught (#2)
Re: Stale Process

On 10 Nov 2002, Doug McNaught wrote:

Terence Leung <tcmleung@yahoo.com> writes:

Dear sir,
I built Apache, PHP-PostgreSql 7.1 web server in Linux
Redhat 7.0.
I always check the process by 'ps -aux' and always
found the stale postmaster processes:

It's most likely that PHP is keeping the connections open for some
reason. The 'postgres' processes are in S (sleep) state, which
indicates that their socket is still being held open by the client
end. So it's probably not a Postgres problem... I find it entirely
unsurprising that PHP might be buggy. ;)

Yes, he should switch immediately to a bug free language, like maybe Java.

It's a poor craftsman who blames his tools.

Anyway, now that we've gotten our jabs in on our non-favorite language,
mayhaps we can help the newbie?

I've never seen PHP hold a connection open when it wasn't opened
using pconnect.

It's possible that some page on the box DOES have a pg_pconnect in it
somewhere. That's where I'd look first.

It's also possible that a user has a psql connection up and running. If
you've got a psql monitor open, you'll see an idle backend process waiting
to take you queries and run them.

Lastly, a single idle process is NO BIG DEAL. If your database only has
two connections to it at idle, and 100 at heavy load, the extra idle
connection is below the noise threshold of "things to be worried about."

#4scott.marlowe
scott.marlowe@ihs.com
In reply to: Terence Leung (#1)
Re: Stale Process

On Sun, 10 Nov 2002, Terence Leung wrote:

Dear sir,
I built Apache, PHP-PostgreSql 7.1 web server in Linux
Redhat 7.0.
I always check the process by 'ps -aux' and always
found the stale postmaster processes:

postgres 9212 0.0 2.1 6136 2408 ? S
Nov09 0:02 postgres: nobody newmy3qdb [local] idle
postgres 10617 0.0 2.4 5628 2740 ? S
Nov09 0:02 postgres: nobody newmy3qdb [local] idle

The processes would not disappear if I don't kill the
processess.
I only use 'pg_connect' but never use
'pg_pconnect'(permanent connection), so why does it
happen and how to solve the problem so that the stale
process can automatically disappear?

As a followup to my previous message, the other possibility is that you
have a PHP page that is segfaulting halfway through, and the connection is
being left hanging since the process died before it could close it.

But the other two possibilities are more still more likely (i.e. psql
is running, or you have a pg_pconnect somewhere you haven't found yet.)