From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | jim_yates <pg(at)wg5jim(dot)net> |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: could not access status of transaction pg_multixact issue |
Date: | 2014-10-09 20:36:37 |
Message-ID: | 20141009203637.GH7043@eldon.alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
jim_yates wrote:
> Then I'm really confused.
> The minimum relminmxid for all the rows in pg_class that have relminmxid
> greater then zero is 1.
> That's the current value of datminmxid in pg_database.
>
> And the NextMultiXactId from pg_controldump is 303464.
>
> So if I use the min value from pg_class then I have some other issue.
>
> Where should I get the new pg_database value from?
I'm deep in another issue which I don't want to page out right now, but
try vacuuming the tables that have relminmxid=1 with low values set for
vacuum_multixact_freeze_table_age and vacuum_multixact_freeze_min_age,
say 100000. (I think 65536 ought to get you beyond segment
pg_multixact/offset/0000, and then that file would be removed.) Since
any multixact values below the point at which pg_upgrade ran should be
marked "no longer running" through hint bits, there would be no
pg_multixact lookups anyway and thus the vacuuming should complete with
no errors.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | jim_yates | 2014-10-09 21:51:05 | Re: could not access status of transaction pg_multixact issue |
Previous Message | jim_yates | 2014-10-09 20:17:06 | Re: could not access status of transaction pg_multixact issue |