作为服务器升级的一部分，我们将从32位Linux迁移到64位Linux（如果Gentoo有所作为）和Postgresql 9.1到9.2。 我有一个时间用pg_upgrade升级数据库…
我的第一个尝试是将旧的（32位9.1）pgsql bin＆lib目录，更新系统，然后在更新的（64位）系统上运行：
pg_upgrade -b pgsql.old/bin -B /usr/lib64/postgresql-9.2/bin -d data.old -D data.new 这会失败，因为pg_upgrade尝试运行错误的libpq.so.5（64位系统版本，而不是pgsql.old / lib中的32位版本）运行pgsql.old / bin / pg_ctl。 如果我将LD_LIBRARY_PATH设置为指向pgsql.old / lib，那么我可以手动运行旧的32位pg_ctl，但是这似乎对pg_upgrade没有帮助。
所以我想我只是安装了64位Postgresql 9.1和9.2。 现在当我运行：
pg_upgrade -b /usr/lib64/postgresql-9.1/bin -B /usr/lib64/postgresql-9.2/bin -d data.old -D data.new
二进制文件运行正常，但升级失败，提前：
old and new pg_controldata alignments are invalid or do not match
我猜是由于在数据库中的32位和64位alignment问题？
我知道，pg_dump / pg_restore将工作得很好，但出于速度的原因，我想尽可能使用pg_upgrade。 这不是一次性交易 – 我们有几百个系统需要以自动的方式进行更新（通过适当脚本的可启动拇指驱动器）。
您不能使用pg_upgrade从32位升级到64位，或者通常从任何OS / CPU /平台升级到任何其他OS / CPU /平台。 数据文件是平台相关的，而pg_upgrade只是通过对数据文件进行复制（或链接）而不改变。 所以这是永远不会工作的。
此时您的select是转储/恢复，或使用逻辑复制系统来移动数据（Slony，Londiste，Bucardo）。
我绝不会像你这样做。 只是为了logging，我一直在使用PostgreSQL，因为哦，6.x天（又名很多年）。
我总是毫无疑问地沿着这样的方向做一些事情：
我使用自定义RC脚本来停止，启动和重新启动postmaster，并在其中设置指向当前数据和xlog目录的设置。
另外，我知道你正在使用一个特定的发行版的包pipe理器。 我避免这一点，并始终从源代码构buildPostgreSQL。