Skip site navigation (1) Skip section navigation (2)

old, dead connections?

From: "Peter Koczan" <pjkoczan(at)gmail(dot)com>
To: pgsql-admin(at)postgresql(dot)org
Subject: old, dead connections?
Date: 2008-05-19 19:04:40
Message-ID: 4544e0330805191204g1df08313j6bcadf71a8be529f@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-admin
Hi all,

I'm looking to upgrade a server to postgres 8.3, but there's one
connection that's being problematic. It continually says it's
UPDATE'ing, but it's been at it for weeks now, and while the database
is big, it shouldn't take weeks.

Even weirder is that it looks like the client-side connection died a
long time ago.

[root(at)haddock] ~ $ ps axvw | grep post
  330 pts/0    S+     0:00      0    75  3820   648  0.0 grep post
14321 ?        S      0:00      9  3274 1056081 20428  0.6
/s/postgresql-8.2.6/bin/postgres -D /scratch.1/postgres/fsstudy-8.2
14323 ?        Ss    19:31     16  3274 1055873 1036904 30.7 postgres:
writer process
14324 ?        Ss     0:00      0  3274  8257  1644  0.0 postgres:
stats collector process
20459 pts/8    S+     0:01      3   227  5480  3444  0.1
/s/postgresql/bin/psql -h haddock -p 5432 fsstudy
20460 ?        Ss   2295:51    27  3274 1057221 1045304 31.0 postgres:
nitina fsstudy haddock.cs.wisc.edu(50957) idle
32247 ?        Rs   17051:22    1  3274 1056653 1043964 30.9 postgres:
nitina fsstudy haddock.cs.wisc.edu(41114) UPDATE

[root(at)haddock] ~ $ netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address               Foreign Address
     State
tcp        0      0 haddock.cs.wisc.:postgresql
haddock.cs.wisc.edu:50957   ESTABLISHED
tcp        0    208 haddock.cs.wisc.edu:ssh     ator.cs.wisc.edu:46929
     ESTABLISHED
tcp        0      0 haddock.cs.wisc.edu:50957
haddock.cs.wisc.:postgresql ESTABLISHED
udp        0      0 localhost:33544             localhost:33544
     ESTABLISHED
...

I'm fairly certain that the connections noted in netstat refer to the
idle connection.

So, I don't want to just kill the connection right now unless I'm
certain it can be done safely. However, I'd like to deal with it as
it's a potential impediment to the upgrade and it's taking up lots of
CPU time on the machine.

Any advice, or any idea of what's going on?

Peter

pgsql-admin by date

Next:From: Vishal MailinglistDate: 2008-05-20 00:46:43
Subject: Buggy PostgreSQL dotNET data providers
Previous:From: Chander GanesanDate: 2008-05-19 15:07:58
Subject: Re: Global / cluster-wide functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group