Re: BUG #13472: VACUUM ANALYZE hangs on certain tables - Mailing list pgsql-bugs

From Matthew Seaman
Subject Re: BUG #13472: VACUUM ANALYZE hangs on certain tables
Date
Msg-id 559118FB.1070605@infracaninophile.co.uk
Whole thread Raw
In response to Re: BUG #13472: VACUUM ANALYZE hangs on certain tables  (Andres Freund <andres@anarazel.de>)
List pgsql-bugs
On 2015/06/26 16:58, Andres Freund wrote:
> On 2015-06-26 16:21:19 +0100, Matthew Seaman wrote:
>> Restarting the DB is going to require all sorts of outage notification=
s
>> and general palaver, so we'd definitely prefer not to that if we can
>> possibly avoid it.
>=20
> Is it feasible to lock the table exclusively for a short time? If so yo=
u
> can just VACUUM FULL them - given the table sizes that should be fairly=

> quick.
>=20
> (The difference between table level exclusive locks and cleanup locks i=
s
> that the latter aren't "fair", i.e. a continious stream of pins will
> block them, whereas heavyweight locks are queued)

We have found the culprit -- a long running query was apparently locking
one of the tables, and killing it has allowed the vacuum to complete.
We had checked pg_locks but for some reason this query wasn't obvious.

Thanks for you help, and I think we can close this one.

    Cheers

    Matthew  (posting from the account I subscribed to the list with, but I
am the same person as matthew.seaman@adestra.com)

pgsql-bugs by date:

Previous
From: Francisco Olarte
Date:
Subject: Re: BUG #13474: Instaling error.
Next
From: Tom Lane
Date:
Subject: Re: BUG #13471: Reload with include_dir results in incorrect "contains errors" message