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:
/*
* 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
