Re: Backend hanging..
От | Mitch Vincent |
---|---|
Тема | Re: Backend hanging.. |
Дата | |
Msg-id | 013101c12748$bf8186b0$1251000a@mitch обсуждение исходный текст |
Ответ на | Backend hanging.. ("Mitch Vincent" <mvincent@cablespeed.com>) |
Список | pgsql-general |
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 >
В списке pgsql-general по дате отправления: