Hi Alvaro,
We did manual vacuum and reindex of room_contract_service_code and it finis=
hed quickly. We still have auto vacuum disabled.
1 ) select oid::regclass, relfrozenxid, relminmxid from pg_class where reln=
ame =3D 'room_contract_service_code'; select datname, datfrozenxid, datminm=
xid from pg_database where datname =3D 'jetblue';
jetblue=3D# select oid::regclass, relfrozenxid, relminmxid from pg_class w=
here relname =3D 'room_contract_service_code'
jetblue-# ;
oid | relfrozenxid | relminmxid
----------------------------+--------------+------------
room_contract_service_code | 953567787 | 20784
(1 row)
jetblue=3D# select datname, datfrozenxid, datminmxid from pg_database where=
datname =3D 'jetblue';
datname | datfrozenxid | datminmxid
---------+--------------+------------
jetblue | 870700471 | 1
(1 row)
2) Latest checkpoint's NextMultiXactId: 23431 =
=
=20
Latest checkpoint's NextMultiOffset: 5678 =
=
=20
Latest checkpoint's oldestMultiXid: 1 =
=
=20
Latest checkpoint's oldestMulti's DB: 16423 =
=
=20
It says the oldest multi is 1, so the database should not have any values b=
etween 1 and 23431 that correspond to pg_upgrade'd multixact values ... so =
what is going on here? Unless the recent mucking with pg_upgrade to handle=
multixact's got something wrong.
We used psotgres 9.3.4 to pg_upgrade from 9.1. We just upgraded binaries to=
9.3.5 just last week ? Would this cause any issues with MultiXid issue.
Thanks
Dinesh