我们目前正在准备新的版本，这些版本将更正全新初始化 (initdb) 的安装中存在的这些问题。但是，由于这些问题实际上是不正确的系统目录条目，因此更新到新版本本身并不能解决现有安装中的问题。相反，数据库管理员必须手动修复目录条目，如下所述。我们发布此公告是为了鼓励 PostgreSQL 安装的管理员尽快执行这些修复。
两个错误中更严重的一个是，支持客户端到服务器字符集转换的函数可以被非特权用户从 SQL 命令中调用，但这些函数的设计并非对恶意参数值选择安全。此问题存在于 PostgreSQL 7.3.* 到 8.0.* 版本中。建议的修复方法是禁用这些函数的公共 EXECUTE 访问权限。这不会影响字符集转换的函数的正常使用，但可以防止滥用。
要完成此更改，请以超级用户身份执行以下 SQL 命令：
``
UPDATE pg_proc SET proacl = '{=}'
WHERE pronamespace = 11 AND pronargs = 5
AND proargtypes[2] = 'cstring'::regtype;
在 7.3.* 到 8.0.* 版本中，此命令应报告已更新 90 行。7.4 及更高版本将报告“警告：默认授权者为用户 ID 1”，可以忽略此警告。
必须在安装的*每个*数据库（包括 template1，并且理想情况下也包括 template0）中执行上述命令。如果您不修复模板数据库，则随后创建的任何数据库都将包含相同的漏洞。template1 可以像任何其他数据库一样修复，但修复 template0 需要其他步骤。首先，从任何数据库发出：
``
UPDATE pg_database SET datallowconn = true WHERE datname = 'template0';
接下来，连接到 template0 并执行 pg_proc 更新。最后，执行：
``
-- 重新冻结 template0
VACUUM FREEZE;
-- 并保护它免受未来更改
UPDATE pg_database SET datallowconn = false WHERE datname = 'template0';
另一个错误是 contrib/tsearch2 模块错误地将几个函数声明为返回类型 "internal"，而它们没有任何 "internal" 参数。这破坏了 "internal" 的类型安全性，允许用户构造 SQL 命令来调用其他接受 "internal" 参数的函数。尚未详细调查此问题的后果，但至少肯定有可能使后端崩溃。
此错误影响 PostgreSQL 7.4 及更高版本，但仅当您安装了 contrib/tsearch2 模块时才会影响。建议的修复方法是更改错误声明的函数，使其接受一个 "internal" 参数，因此不能直接从 SQL 命令中调用。
要执行此操作，请以超级用户身份执行以下命令：
``
UPDATE pg_proc SET proargtypes[0] = 'internal'::regtype
WHERE oid IN (
'dex_init(text)'::regprocedure,
'snb_en_init(text)'::regprocedure,
'snb_ru_init(text)'::regprocedure,
'spell_init(text)'::regprocedure,
'syn_init(text)'::regprocedure
);
此命令应报告已更新 5 行。（如果失败并出现类似“函数“dex_init(text)”不存在”的消息，则要么未在此数据库中安装 tsearch2，要么您已经执行了更新。）
您需要在安装了 tsearch2 的*每个*数据库（包括 template1）中执行此操作。但是，您无需担心 template0，因为它肯定不包含 tsearch2。
如果您经常在新数据库中安装 tsearch2，您还需要修改 tsearch.sql 脚本，以便首先将这些函数声明为采用内部类型。（脚本修复将成为即将发布的版本的一部分，因此您可以等待这些版本。）
我代表 PostgreSQL 核心委员会，为这些错误可能引起的任何问题表示歉意。
此致，汤姆·莱恩
此帖子已从 PostgreSQL 网站的早期版本迁移而来。对于迁移造成的任何格式问题，我们深表歉意。