From: | Brian Ghidinelli <brian(at)vfive(dot)com> |
---|---|
To: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #13970: Vacuum hangs on particular table; cannot be terminated - requires `kill -QUIT pid` |
Date: | 2016-02-19 01:16:26 |
Message-ID: | 5E032A4D-801B-44FF-8FFA-FF00E08F0A7E@vfive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> On Feb 18, 2016, at 12:59, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>
> Okay, great. What would be most helpful is figuring out the pg_upgrade
> history of this server; if you have copies of the cluster just before
> the upgrade, to extract the "nextMultiXactId" value, that would be
> useful.
Unfortunately we removed the 9.3 data dir for space reasons… I may have backups from then so maybe I could spin up a docker container and restore it but would that tell us the same thing?
> How large is this table? We could try to scan it to look for the values
> that are causing the problem, and set oldestMxact to one that would not
> cause a problem.
Database size is 34gb. This particular table is only 105MB. If you account for all of the relations and indices it’s 239MB. There is one table in the system which is 17GB that stores email campaigns and deliveries. Everything else is all pretty small-ish at 2.5gb or under.
How do you query for oldestMxact?
> How large is the cluster? For experimentation, it would be very useful
> if you could take a copy of it, on a server where you could recompile
> with debugging symbols.
Is there a Docker container by chance that has symbols enabled? That would make standing up a test environment a lot easier. Our production infrastructure is not yet inside Docker but we run it in dev and it’s easy to spin up and throw away.
Brian
From | Date | Subject | |
---|---|---|---|
Next Message | andreas.papst | 2016-02-19 09:18:38 | BUG #13974: temp_file_limit effects vacuum |
Previous Message | Michael Paquier | 2016-02-19 01:02:17 | Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby |