> On Feb 18, 2016, at 12:59, Alvaro Herrera <alvherre@2ndquadrant.com> =
wrote:
>=20
> 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=E2=80=A6 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=E2=80=99s 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=E2=80=99=
s easy to spin up and throw away.
Brian