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

On Fri, Jun 27, 2014 at 05:05:21PM -0400, Alvaro Herrera wrote:
> Another thing probably worth doing is have pg_upgrade set
> pg_database.datminmxid to the minimum of pg_class.relminmxid on each
> database. Right now these values are all initialized to 1, which is a
> problem. We have set_frozenxids() which appears to be related, although
> I don't readily understand what that is doing.

Yikes, OK. What pg_upgrade's set_frozenxids() does is to set the
database and relation frozen xids to be the current xid, particularly
template0 and the system tables, then pg_dump --binary-upgrade adjusts
many of them to match the old cluster. What isn't happening, as you
pointed out, is that we are not dealing with the new database and
relation-level minmxid values in pg_upgrade or pg_dump --binary-upgrade.
The attached 1k-line patch fixes that.

What I am not sure about is how to set values from pre-9.3 clusters, and
whether 9.3 pg_upgrade upgrades from pre-9.3 clusters are a problem.
Are users who used pg_upgrade to go to 9.4 beta in trouble?

I also have no way to know what value to use for pre-9.3 clusters --- I
used controldata.chkpnt_nxtmulti in pg_upgrade (because the value was
accessible), but 0 in pg_dump/pg_dumpall, like we already do for frozen
xid values, but that usage is for major versions that pg_upgrade doesn't
support, so it might be the wrong default. I am thinking that should be
using controldata.chkpnt_nxtmulti, which exists back to 8.4, but I have
no access to that value from pg_dump. In fact, the patch as it exists
is flawed because it uses controldata.chkpnt_nxtmulti to set values from
set_frozenxids(), because the value is accessible, but uses zero in
pg_dump and pg_dumpall for pre-9.3 old clusters. :-(

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +