"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