From: | Matthew Seaman <m(dot)seaman(at)infracaninophile(dot)co(dot)uk> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #13472: VACUUM ANALYZE hangs on certain tables |
Date: | 2015-06-29 10:07:55 |
Message-ID: | 559118FB.1070605@infracaninophile.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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 notifications
>> and general palaver, so we'd definitely prefer not to that if we can
>> possibly avoid it.
>
> Is it feasible to lock the table exclusively for a short time? If so you
> can just VACUUM FULL them - given the table sizes that should be fairly
> quick.
>
> (The difference between table level exclusive locks and cleanup locks is
> 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(dot)seaman(at)adestra(dot)com)
From | Date | Subject | |
---|---|---|---|
Next Message | Xavier 12 | 2015-06-29 12:04:43 | Re: pg_xlog on a hot_stanby slave |
Previous Message | vinothkumar.rajendran | 2015-06-29 09:52:04 | BUG #13476: Access Denied |