Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-07-20 13:37:01 -0400, Tom Lane wrote:
>> I started transcribing Bruce's proposed fix procedure at
>> https://wiki.postgresql.org/wiki/20140702pg_upgrade_fix
>> into the release notes, but I'm afraid it's all wet.
> I don't understand why we should do anything but remove the 0000 file if
> it's all zeroes? This seems far too complicated. Beside the fact that I
> doubt it's actually achieving anything reliably?
This one is not about the extra 0000 file. It's about whether datminmxid
and relminmxid are wrong. In the previous coding of pg_upgrade, they'd
have been left at "1" even if that value has wrapped around into the
future.
Now, if you were lucky, you'd have no bad side-effects even if they had
wrapped around ... but if you're not so lucky, you'd get failures due to
accesses to nonexistent pg_multixact files, after vacuum has truncated
pg_multixact in the mistaken impression that there are no remaining
references to old mxids.
The solution I just proposed of forcing the minmxid values down to
"now - 2E9" is not that great btw; I think it will result in autovacuum
deciding it has to scan everything in sight, which is the sort of
intensive operation that pg_upgrade was intended to avoid. I'm not sure
we have any alternatives though.
regards, tom lane