运行7.4.X的用户不需要转储/恢复。不过， 作为合并修复在最初的7.4.X系统目录中发现的两个错误的最简单的方法，这应该会是明智的。 使用7.4.2的initdb的dump/initdb/reload序列将自动纠正这些问题。

更严重的两个错误是数据类型anyarray有错误的对齐标签； 这是一个问题，因为pg_statistic系统目录使用anyarray字段。 贴错标签会引起规划器错误估计甚至当包含WHERE 子句的规划器查询在两端对齐的字段(如float8和timestamp)上时会崩溃。 强烈建议所有安装都修复这个错误，通过initdb或遵循下面给出的手动修复程序。

较小的错误是系统视图pg_settings应该被标记为有公共更新访问， 以允许UPDATE pg_settings用作SET的替代。 这也可以通过initdb或者手动修复，但是没有必要修复，除非你想要使用UPDATE pg_settings。

如果你不愿意做initdb，那么下面的程序将修复pg_statistic。 作为数据库超级用户，执行：

-- clear out old data in pg_statistic:
DELETE FROM pg_statistic;
VACUUM pg_statistic;
-- this should update 1 row:
UPDATE pg_type SET typalign = 'd' WHERE oid = 2277;
-- this should update 6 rows:
UPDATE pg_attribute SET attalign = 'd' WHERE atttypid = 2277;
--
-- At this point you MUST start a fresh backend to avoid a crash!
--
-- repopulate pg_statistic:
ANALYZE;

这可以在活动的数据库中完成，但是要注意所有运行在改变了的数据库中的后端都必须在 重新填充pg_statistic是安全的之前重新启动。

要修复pg_statistic错误，只需要做：

GRANT SELECT, UPDATE ON pg_settings TO PUBLIC;

上面的程序必须在每个安装的数据库中执行，包括template1， 理想上也包括template0。如果你没有修复模板数据库， 那么任何随后创建的数据库都将包含相同的错误。template1的修复方式和其他数据库相同， 但是修复template0需要额外的步骤。首先，从任意数据库中发出：

UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';

下一步，连接到template0，并执行上面的修复步骤。最后，执行：

-- re-freeze template0:
VACUUM FREEZE;
-- and protect it against future alterations:
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';

版本7.4.2合并了所有包含在版本7.3.6中的修复，加上下面的修复：