Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-07-20 17:22:48 -0400, Tom Lane wrote:
>> 4. The patch Bruce applied to initialize datminmxid/relminmxid to the old
>> NextMultiXactId rather than 1 does not fundamentally change anything here.
>> It narrows the window in which wraparound can cause problems, but only by
>> the distance that "1" is in-the-future at the time of upgrade.

> I think it's actually more than that. Consider what happens if
> pg_upgrade has used pg_resetxlog to set nextMulti to > 2^31. If
> rel/datminmxid are set to 1 regardless vac_update_relstats() and
> vac_update_datfrozenxid() won't increase them anymore because of:
> /* relminmxid must never go backward, either */
> if (MultiXactIdIsValid(minmulti) &&
> MultiXactIdPrecedes(pgcform->relminmxid, minmulti))
> {
> pgcform->relminmxid = minmulti;
> dirty = true;
> }

> And that can actually cause significant problems once 9.3+ creates new
> multis because they'll never get vacuumed away but still do get
> truncated. If it's an updating multi xmax that can effectively make the
> row unreadable - not just block updates.

No, I don't think so. Truncation is driven off oldestMultiXid from
pg_control, not from relminmxid. The only thing in-the-future values of
those will do to us is prevent autovacuum from thinking it must do a full
table scan. (In particular, in-the-future values do not cause
oldestMultiXid to get advanced, because we're always looking for the
oldest value not the newest.)

But in any case, we both agree that setting relminmxid to equal nextMulti
is completely unsafe in a 9.3 cluster that's already been up. So the
proposed fix instructions are certainly wrong.

regards, tom lane