对于运行 7.4.X 的用户，不需要进行转储/恢复。不过，作为合并 7.4.X 系统目录初始内容中发现的两个错误的修复的最简单方法，它可能是可取的。用 7.4.2 的 initdb 做转储/initdb/重载序列会自动纠正这些问题。

两个错误中较严重的是数据类型 anyarray 的对齐标签错误；这是一个问题，因为 pg_statistic 系统目录使用 anyarray 列。当规划涉及双对齐列（如 float8 和 timestamp）上 WHERE 子句的查询时，错误标记可能导致规划器误估甚至崩溃。强烈建议所有安装通过 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_settings 错误，只需执行：

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 版本中的所有修复，外加以下修复：