locked up backends
Hello,
We are running Postgres 7.0.2 on Linux RH 6.2 Dell servers.
When traffic gets heavy we often get one of the backend locked up in an
UPDATE, INSERT or COMMIT request. Eventually all the other backends end
up locking too as they try to access a row locked by the original
backend. The output of 'ps' shows that the locked up backend is sleeping
waiting for 'select' to return.
This has been occurring once or twice a day for the past few months. We
just stop the postmaster (sometimes we need to kill -USR1 one of the
backends before they all disappear) and then we restart postmaster and
everything works fine until the next lock up.
Any idea what might be wrong? I'd be happy to provide more info, if only
I knew what.
Thanks in advance,
--Maurice
Maurice Balick <balm@smiley.com> writes:
Hello,
We are running Postgres 7.0.2 on Linux RH 6.2 Dell servers.
As I understand it, 7.0.3 fixes some severe bugs in earlier 7.0
versions. You should upgrade to 7.0.3 at the very least, and consider
upgrading to 7.1, which is currently in Release Candidate status and
offers considerable improvements in performance, stability and
features.
-Doug
Import Notes
Reply to msg id not found: MauriceBalick'smessageofThu05Apr2001171744-0400
Maurice Balick <balm@smiley.com> writes:
We are running Postgres 7.0.2 on Linux RH 6.2 Dell servers.
When traffic gets heavy we often get one of the backend locked up in an
UPDATE, INSERT or COMMIT request. Eventually all the other backends end
up locking too as they try to access a row locked by the original
backend.
Try updating to 7.0.3. You may be getting caught by 7.0.2's failure to
release locks when a client disconnects partway through a transaction
block.
If you still see this in 7.0.3 then it'd be worth further investigation.
regards, tom lane
I see this pretty often on 7.1b4, running on redhat linux 6.2 (or 7.0;
same problem on both). My lockups are always either INSERT or UPDATE,
and all the other backends are shown as "idle in transaction".
I've been trying to track this down, but haven't had any luck.
Suggestions?
Thanks,
-Randy
Show quoted text
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Thursday, April 05, 2001 4:12 PM
To: Maurice Balick
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] locked up backendsMaurice Balick <balm@smiley.com> writes:
We are running Postgres 7.0.2 on Linux RH 6.2 Dell servers.
When traffic gets heavy we often get one of the backend
locked up in an
UPDATE, INSERT or COMMIT request. Eventually all the other
backends end
up locking too as they try to access a row locked by the original
backend.Try updating to 7.0.3. You may be getting caught by 7.0.2's
failure to
release locks when a client disconnects partway through a transaction
block.If you still see this in 7.0.3 then it'd be worth further
investigation.regards, tom lane
---------------------------(end of
broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
Import Notes
Resolved by subject fallback
"Randall F. Kern" <randy@spoke.net> writes:
I see this pretty often on 7.1b4, running on redhat linux 6.2 (or 7.0;
same problem on both). My lockups are always either INSERT or UPDATE,
and all the other backends are shown as "idle in transaction".
Oh? 7.1 doesn't have the problem I was thinking of, so you may have a
different issue. Could you attach to the stuck backends with gdb and
get a backtrace from each one, so we can see approximately what they're
doing? (It'd help if you've compiled with debug symbols.)
regards, tom lane
On Thu, 5 Apr 2001, Tom Lane wrote:
"Randall F. Kern" <randy@spoke.net> writes:
I see this pretty often on 7.1b4, running on redhat linux 6.2 (or 7.0;
same problem on both). My lockups are always either INSERT or UPDATE,
and all the other backends are shown as "idle in transaction".Oh? 7.1 doesn't have the problem I was thinking of, so you may have a
different issue. Could you attach to the stuck backends with gdb and
get a backtrace from each one, so we can see approximately what they're
doing? (It'd help if you've compiled with debug symbols.)
How 'bout this version?
PostgreSQL 7.0.2 on i386-unknown-freebsdelf3.2, compiled by gcc 2.7.2.1
I was away all day and came back to a logcheck message about running
out of swap and a process being killed. ps -axww showed a number of
these:
/usr/local/pgsql/bin/postgres nobody 127.0.0.1 twig idle
twig's a web based pim. I also noticed a bunch of messages that told
me there were some messages that imapd had trouble with. ISTM that
these should've been killed off by something before the OS did it. I
killed them off (9 of them) by HUPping httpd. Is this closer to what
you were thinking?
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
Online Campground Directory http://www.camping-usa.com
Online Giftshop Superstore http://www.cloudninegifts.com
==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
I was away all day and came back to a logcheck message about running
out of swap and a process being killed. ps -axww showed a number of
these:
/usr/local/pgsql/bin/postgres nobody 127.0.0.1 twig idle
Those aren't deadlocked, they're just waiting for their clients to
do something. You might have a problem on the client side ...
regards, tom lane