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.