i've had similar problems before. Looks like some thing is in a transaction,
blocked on something else. Then vacuum comes in, locks half the tables, and
then gets stuck on a table that the transaction has modified. Now most of
your other transactions will block forever. Then the connection limit for
postgres will be hit. Then you can't connect to postgres at all.

Basically, its a death spiral starting from something in a transaction
blocking forever on an external command. Nothing postgres itself can do
about. Of course, this is just my conjecture based on the info provided.

-rchit

-----Original Message-----
From: Michael Meskes [mailto:meskes@postgresql.org]
Sent: Thursday, October 11, 2001 2:29 AM
To: PostgreSQL Hacker
Subject: [HACKERS] Deadlock? idle in transaction


A customer's machine hangs from time to time. All we could find so far is
that postgres seems to be in state "idle in transaction":

postgres 19317  0.0  0.3  8168  392 ?        S    Oct05   0:00
/usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data
postgres 19983  0.0  0.8  8932 1020 ?        S    Oct05   0:01 postgres:
postgres rabatt 192.168.50.222 idle in transaction
postgres 21005  0.0  0.0  3484    4 ?        S    Oct06   0:00
/usr/lib/postgresql/bin/psql -t -q -d template1
postgres 21014  0.0  0.7  8892  952 ?        S    Oct06   0:01 postgres:
postgres rabatt [local] VACUUM waiting
postgres 21833  0.0  0.4  3844  572 ?        S    Oct06   0:00
/usr/lib/postgresql/bin/pg_dump rabatt
postgres 21841  0.0  1.2  9716 1564 ?        S    Oct06   0:00 postgres:
postgres rabatt [local] COPY waiting
postgres 22135  0.0  0.9  8856 1224 ?        S    Oct06   0:00 postgres:
postgres rabatt 192.168.50.223 idle in transaction waiting

I'm not sure what's happening here and I have no remote access to the
machine myself. Any idea what could be the reason for this?

There may be some client processes running at the time the dump and the
vacuum commands are issued that have an open transaction doing nothing. That
is the just issued a BEGIN command. Thinking about it run some inserts at
the very same time, although that's not likely.

Any hints are appreciated. Thanks in advance.

Michael

-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Thu, 11 Oct 2001 15:15:36 -0700
Rachit Siamwalla <rachit@ensim.com>
Re: Deadlock? idle in transaction
On Thu, Oct 11, 2001 at 03:15:36PM -0700, Rachit Siamwalla wrote:
> then gets stuck on a table that the transaction has modified. Now most of
> your other transactions will block forever. Then the connection limit for
> postgres will be hit. Then you can't connect to postgres at all.

Really? I do not know the way the backend handles locks, but couldn't it
detect such a deadlock and cancel a transaction? Something like this:

task 1 locks table A
task 2 locks table B
task 1 locks table B
task 2 tries to lock table A

Of course the last call creates the deadlock. Would it be possible to just
cancel task 2 in this case? Or do I miss something obvious?

Michael

-- 
Michael Meskes
Michael@Fam-Meskes.De
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!

Fri, 12 Oct 2001 10:34:09 +0200
Michael Meskes <meskes@postgresql.org>
Re: Deadlock? idle in transaction