2015-05-07 13:43 GMT+02:00 Alvaro Herrera <alvhe...@2ndquadrant.com>:
> The problem is here:
>
> > [root@ps-test5:/etc/puppet/modules/postgresql/files] pg_controldata
> > /mnt/ebs/pgsql/data
> > pg_control version number: 922
> > Catalog version number: 201302181
>
> The catversion for 9.2 is 201204301; you have modified it with your
> patches in a way that breaks this check in pg_upgrade:
>
yes, It was a reason.
Thank you very much for help
Regards
Pavel
>
> /*
> * If the old server is before the MULTIXACT_FORMATCHANGE_CAT_VER
> change
> * (see pg_upgrade.h) and the new server is after, then we don't copy
> * pg_multixact files, but we need to reset pg_control so that the new
> * server doesn't attempt to read multis older than the cutoff value.
> */
> if (old_cluster.controldata.cat_ver >= MULTIXACT_FORMATCHANGE_CAT_VER
> &&
> new_cluster.controldata.cat_ver >= MULTIXACT_FORMATCHANGE_CAT_VER)
>
> pg_upgrade behaves differently if the source catversion is earlier than
> this value:
>
> /*
> * pg_multixact format changed in 9.3 commit
> 0ac5ad5134f2769ccbaefec73844f85,
> * ("Improve concurrency of foreign key locking") which also updated
> catalog
> * version to this value. pg_upgrade behavior depends on whether old and
> new
> * server versions are both newer than this, or only the new one is.
> */
> #define MULTIXACT_FORMATCHANGE_CAT_VER 201301231
>
> because it expects to see the "oldest multixact id" in pg_controldata,
> but 9.2 did not have that.
>
> You either need to change your database's catversion, or patch your
> pg_upgrade so that it knows to consider your catversion part of 9.2
> instead of 9.3.
>
> --
> Álvaro Herrera http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
