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

I wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> writes:
>> If any *single* full table vacuum after that calls
>> vac_update_datfrozenxid() which just needs its datfrozenxid advance by
>> one we're in trouble: vac_truncate_clog() will be called with minMulti =
>> GetOldestMultiXactId().

> Uh, no, the cutoff is GetOldestMultiXactId minus
> vacuum_multixact_freeze_min_age (or the autovac equivalent).

Oh, wait, I see what you're on about: that cutoff doesn't constrain
the global value computed by vac_truncate_clog. Hmm.

I wonder whether we should change vac_update_relstats so that it only
applies the "relminxid mustn't go backwards" rule as long as relminxid
is sane, ie, not in the future. If it is in the future, forcibly update
it to the cutoff we actually used. Likewise for relminmxid. And I guess
we'd need a similar rule for updating datmin(m)xid.

regards, tom lane