Greetings, Looks like we might not be entirely out of the woods yet regarding MultiXactId's. After doing an upgrade from 9.2.6 to 9.3.4, we saw the following:
ERROR: MultiXactId 6849409 has not been created yet -- apparent wraparound
The table contents can be select'd out and match the pre-upgrade
backup, but any attempt to VACUUM / VACUUM FULL / CLUSTER fails,
unsurprisingly.
I've just started looking into this, but here's a bit more data-
The *NEW* (9.3.4) cluster's pg_multixact files:
pg_multixact/members/
-rw------- 1 postgres postgres 8192 Mar 30 02:33 0000
pg_multixact/offsets/
-rw------- 1 postgres postgres 8192 Mar 28 01:11 0000
-rw------- 1 postgres postgres 122880 Mar 30 02:33 0018
The *OLD* (9.2.6) cluster's pg_multixact files:
pg_multixact/members/
-rw-rw-r-- 1 postgres postgres 188416 Mar 30 03:07 0044
pg_multixact/offsets/
-rw-rw-r-- 1 postgres postgres 114688 Mar 30 03:07 0018
txid_current - 40297693
datfrozenxid - 654
autovacuum_freeze_max_age, vacuum_freeze_min_age,
vacuum_freeze_table_age, multixact GUCs are commented out / default
values.
The *NEW* (9.3.4) control data shows:
pg_control version number: 937
Catalog version number: 201306121
Latest checkpoint's NextXID: 0/40297704
Latest checkpoint's NextOID: 53773598
Latest checkpoint's NextMultiXactId: 1601771
Latest checkpoint's NextMultiOffset: 1105
Latest checkpoint's oldestXID: 654
Latest checkpoint's oldestXID's DB: 12036
Latest checkpoint's oldestActiveXID: 40297704
Latest checkpoint's oldestMultiXid: 1601462
Latest checkpoint's oldestMulti's DB: 0
The *OLD* (9.2.6) control data had:
pg_control version number: 922
Catalog version number: 201204301
Latest checkpoint's NextXID: 0/40195831
Latest checkpoint's NextOID: 53757891
Latest checkpoint's NextMultiXactId: 1601462
Latest checkpoint's NextMultiOffset: 4503112
Latest checkpoint's oldestXID: 654
Latest checkpoint's oldestXID's DB: 12870
Latest checkpoint's oldestActiveXID: 0
(It doesn't report the oldestMulti info under 9.2.6).
The pg_upgrade reported:
Setting oldest multixact ID on new cluster
While testing, I discovered that this didn't appear to happen with a
(earlier) upgrade to 9.3.2. Don't know if it's indicative of
anything.
Here is what pageinspace shows for the record:
-[ RECORD 1 ]--------
lp | 45
lp_off | 5896
lp_flags | 1
lp_len | 50
t_xmin | 9663920
t_xmax | 6849409
t_field3 | 26930
t_ctid | (0,45)
t_infomask2 | 5
t_infomask | 6528
t_hoff | 24
t_bits |
t_oid |
Which shows xmax as 6849409 and HEAP_XMAX_IS_MULTI is set. This is
the only tuple in the table which has HEAP_XMAX_IS_MULTI and the xmax
for all of the other tuples is quite a bit higher (though all are
visible currently).
Thoughts?
Thanks,
Stephen
signature.asc
Description: Digital signature
