From: Stephen Frost <sfrost@snowman.net>
To: pgsql-hackers@postgresql.org
Subject: MultiXactId error after upgrade to 9.3.4
Date: Sun, 30 Mar 2014 00:00:30 -0400
Message-ID: <20140330040029.GY4582@tamriel.snowman.net> (raw)
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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
Attachments:
[application/pgp-signature] signature.asc (835B, ../20140330040029.GY4582@tamriel.snowman.net/2-signature.asc)
download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net
Subject: Re: MultiXactId error after upgrade to 9.3.4
In-Reply-To: <20140330040029.GY4582@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox