| 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: | Whole Thread | Raw Message | 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 |