Re: pg_upgrade stores an invalid datminmxid/relminmxid when the old cluster's newest multixact is 0xFFFFFFFF

Hi Zsolt,

> > servers before v19 skip 0 only when the next multixid is assigned.
>
> It doesn't seem to be 19 specific to me?

You're right, it isn't 19-specific, and that line in the commit message was
misleading. The bug is in set_frozenxids() and dates back to 2014; what
changed is only whether you can reach it:

- pg_upgrade to 14 still fails earlier, in pg_resetwal ("multitransaction ID
(-m) must not be 0"), because 8747b969fd8 was not backpatched to 14, so 14
is not affected.
- pg_upgrade to 15..18 has been able to store the 0 since 8747b969fd8 made
pg_resetwal accept -m 0.
- 19 and master reach the same code through the multixact conversion path.

The only part that is really about 19 is the trigger: a pre-19 server leaves
NextMultiXactId = 0 in the control file after assigning 0xFFFFFFFF, while
since 87a350e1f28 a 19 server never stores 0. I checked by recompiling:
14..18 clusters record 0, 19 and master record 1, so only a pre-19 old
cluster reaches it. And the 0 is not only template0's datminmxid -- it is the
relminmxid of the initdb-created catalogs in every database.

Attached is v3 for master, with the commit message rewritten and
Backpatch-through: 15, plus per-branch versions for 19 down to 15. The
back-branch files are attached as .txt so the cfbot does not try to apply
them to master. 007_multixact_conversion.pl only exists in 19+, so the
15..18 versions add a small same-version test. On every branch the test
fails without the fix and passes with it, and every old-version ->
target-version combination is clean with it.

Regards,
Manu