Alvaro Herrera-9 wrote
> 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
I set vacuum_multixact_freeze_table_age and vacuum_multixact_freeze_min_age
to 100,000 and vacuumed all the tables with a relminmxid='1' and relkind='r'
using pg_class as the source.
I still couldn't vacuum or select the original table with the issue.
I did solve the problem by dropping the table and restoring from my standby
server.
Is there else anything I need to do to prevent being bitten by this bug
again?
I still have a value of 1 for datminmxid in pg_database, and the 0000 file
is still in pg_multixact/members and offsets.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/could-not-access-status-of-transaction-pg-multixact-issue-tp5822248p5822573.html
Sent from the PostgreSQL - sql mailing list archive at Nabble.com.
