From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Mark Steben <msteben(at)autorevenue(dot)com> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Concurrency question |
Date: | 2009-07-07 20:24:18 |
Message-ID: | dcc563d10907071324x2529040v52bf955dc8651901@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
2009/7/7 Mark Steben <msteben(at)autorevenue(dot)com>:
> 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.
Not sure what you mean by formerly was part of a transaction. If the
transaction has rolled back, then the vacuum can proceed. If the
transaction is till open, then it's not formerly a part of it, it IS a
part of it. Either way, open transactions block vacuum on updated
tables.
> Could it be that it hung because it was
> A transaction? Even so I thought those lock types were compatible.
Nope. If you've got an idle transaction that's updated tuples, the
vacuum waits on it. Long running / idle transactions are generally a
bad thing.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-07-07 21:40:35 | Re: Concurrency question |
Previous Message | Scott Marlowe | 2009-07-07 19:53:44 | Re: Catching up Production from Warm Standby after maintenance - Please help |