E.2. 版本 7.4.2

发布日期: 2004-03-08

这个版本包含自 7.4.1 以来的各种补丁。

E.2.1. 移植到版本 7.4.2

对于运行 7.4.X 的用户,不需要转储/重载。不过,转储/重载是修复在 7.4.X 版本的系统表里面的两个错误的最简单的方法。 使用 7.4.2 的 initdb 然后走一遍转储/initdb/重载序列将自动修复这些问题。

这两个错误中更严重的是数据类型 anyarray 的对齐标签是错误的; 这个有问题是因为 pg_statistic 系统表使用 anyarray 字段。 这个标签错误可能导致规划器在规划涉及使用双精度对齐的字段(比如 float8timestamp)的 WHERE 子句的时候估计错误甚至是崩溃。我们强烈建议所有安装都修复这个错误,要么是通过 initdb,要么是使用下面介绍的手工修复方法。

弱一些的错误是系统视图 pg_settings 应该标志为公共的更新访问, 以允许 UPDATE pg_settings 用于 SET 的替代。 这个也可以通过 initdb 或者手工修复,不过除非你想使用 UPDATE pg_settings,否则不是必须的。

如果你不想做 initdb,下面的步骤可以修复 pg_statistic。 以数据库超级用户身份,做下面的操作:

-- 清除 pg_statistic 里的旧数据:
DELETE FROM pg_statistic;
VACUUM pg_statistic;
-- 这个会更新 1 行:
UPDATE pg_type SET typalign = 'd' WHERE oid = 2277;
-- 这个会更新 6 行:
UPDATE pg_attribute SET attalign = 'd' WHERE atttypid = 2277;
--
-- 这个时候你必须启动一个新的后端以避免崩溃!
--
-- 重新填充 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 然后执行上面的修复过程。最后,

-- 重新冻结 template0:
VACUUM FREEZE;
-- 然后保护它避免进一步的更改:
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';

E.2.2. 修改

版本 7.4.2 包含所有版本 7.3.6 的补丁,加上下面这些修补: