Re: Backend hanging..

Ack, no wonder I couldn't find a problem with PG - the problem wasn't there
at all...

Sorry for wasting everyone's time, thanks to all that responded!

-Mitch

----- Original Message -----
From: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Mitch Vincent" <mvincent(at)cablespeed(dot)com>
Cc: <pgsql-general(at)postgresql(dot)org>
Sent: Friday, August 17, 2001 1:39 PM
Subject: Re: [GENERAL] Backend hanging..

> "Mitch Vincent" <mvincent(at)cablespeed(dot)com> writes:
> > 61812 p2 S 0:00.58 postmaster: postgres brw [local] VACUUM
waiting
> > (postgres)
> > 61823 p2 I 0:01.18 postmaster: postgres brw 127.0.0.1 idle in
> > transaction (postgres)
> > 61836 p2 S 0:01.03 postmaster: postgres brw 127.0.0.1 UPDATE
waiting
> > (postgres)
> > 61860 p2 S 0:00.99 postmaster: postgres brw 127.0.0.1 idle in
> > transaction waiting (postgres)
> > 61880 p2 S 0:00.99 postmaster: postgres brw 127.0.0.1 idle in
> > transaction waiting (postgres)
>
> Looks to me like backend 61823 is the culprit. Probably it holds a read
> or write lock on that table, and its client is twiddling its thumbs
> instead of committing the transaction so the lock could be released.
> This wouldn't hurt so much if it weren't for the VACUUM --- the VACUUM
> wants an exclusive lock, so it's got to wait, and then subsequent lock
> requests queue up behind the VACUUM (even though they'd not conflict
> with the original read or write lock).
>
> Clients that sit around with open transactions are bad news for
concurrency.
>
> regards, tom lane
>