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@sss.pgh.pa.us>
To: "Mitch Vincent" <mvincent@cablespeed.com>
Cc: <pgsql-general@postgresql.org>
Sent: Friday, August 17, 2001 1:39 PM
Subject: Re: [GENERAL] Backend hanging..
> "Mitch Vincent" <mvincent@cablespeed.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
>
