From: | "Mark Steben" <msteben(at)autorevenue(dot)com> |
---|---|
To: | <pgsql-admin(at)postgresql(dot)org> |
Subject: | Concurrency question |
Date: | 2009-07-07 19:26:54 |
Message-ID: | 20090707192727.98C9563381A@mail.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Any help here appreciated.
I ran a vacuum verbose analyze on a database over the weekend. It ran fine
until it tried to vacuum a table less than 2000 pages. It successfully
acquired a ShareUpdateExclusiveLock as I would expect.
There was an idle thread that had an AccessSharelock on the same table.
Compatible locks I would think. But the vacuum hung until the
AccessSharelock thread was cancelled - 11 hours in all.
This table normally vacuums in less than 15 seconds. This AccessSharelock
came from a query that formerly was part of a transaction sent from a remote
server. Could it be that it hung because it was
A transaction? Even so I thought those lock types were compatible.
As always thanks for your time.
Mark Steben│Database Administrator│
@utoRevenueR "Join the Revenue-tion"
95 Ashley Ave. West Springfield, MA., 01089
413-243-4800 x1512 (Phone) │ 413-732-1824 (Fax)
@utoRevenue is a registered trademark and a division of Dominion Enterprises
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2009-07-07 19:45:30 | Re: Catching up Production from Warm Standby after maintenance - Please help |
Previous Message | Kevin Grittner | 2009-07-07 17:54:47 | Re: Catching up Production from Warm Standby aftermaintenance - Please help |