9.3 9.4 9.5 9.6 10 11 12
阿里云PostgreSQL 问题报告 纠错本页面

E.181. 版本 7.4.2

发布日期: 2004-03-08

这个版本包含各种自7.4.1以来的修复。关于7.4主版本的新特性的信息, 请查阅第 E.183 节

E.181.1. 迁移到版本 7.4.2

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

更严重的两个错误是数据类型anyarray有错误的对齐标签; 这是一个问题,因为pg_statistic系统目录使用anyarray字段。 贴错标签会引起规划器错误估计甚至当包含WHERE 子句的规划器查询在两端对齐的字段(如float8timestamp)上时会崩溃。 强烈建议所有安装都修复这个错误,通过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';

E.181.2. 修改列表

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

<
/BODY >