2009/7/7 Mark Steben <msteben@xxxxxxxxxxxxxxx>: > 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. -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
