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

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-07-20 19:37:15 -0400, Tom Lane wrote:
>>> 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.

>> I'm wondering the same.

Here's a draft patch for this. I think this will fix all cases where
the "1" minmxid inserted by previous pg_upgrade versions is actually
in the future at the time we run VACUUM. We would still be at risk if
it had been in the future when pg_upgrade ran but no longer is now,
since that would mean there could be non-lock-only mxids on disk that
are older than "1". However, for the reasons discussed upthread, it
seems fairly unlikely to me that people would actually get burnt in
practice, so I'm satisfied with doing this much and no more.

I noticed while poking at it that there was an additional small logic
error in vac_update_datfrozenxid: if we decide to update only one of
datfrozenxid and datminmxid, the value passed to vac_truncate_clog for the
other field was *not* the value stored in pg_database but the value we'd
decided not to use. That didn't seem like a good thing; it'd at least
result in possibly using MyDatabaseId as oldestxid_datoid or
minmulti_datoid for a value that doesn't actually match our database.

Barring objections I'll commit this tomorrow.

regards, tom lane