All,
* Stephen Frost (sfrost@snowman.net) wrote:
> 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
While trying to get the production system back in order, I was able to
simply do:
select * from table for update;
Which happily updated the xmax for all of the rows- evidently without
any care that the MultiXactId in one of the tuples was considered
invalid (by at least some parts of the code).
I have the pre-upgrade database and can upgrade/rollback/etc that pretty
easily. Note that the table contents weren't changed during the
upgrade, of course, and so the 9.2.6 instance has HEAP_XMAX_IS_MULTI set
while t_xmax is 6849409 for the tuple in question- even though
pg_controldata reports NextMultiXactId as 1601462 (and it seems very
unlikely that there's been a wraparound on that in this database..).
Perhaps something screwed up xmax/HEAP_XMAX_IS_MULTI under 9.2 and the
9.3 instance now detects that something is wrong? Or is this a case
which was previously allowed and it's just in 9.3 that we don't like it?
Hard for me to see why that would be the case, but this really feels
like HEAP_XMAX_IS_MULTI was incorrectly set on the old cluster and the
xmax in the table was actually a regular xid.. That would have come
from 9.2 though.
Thanks,
Stephen
