我們目前正在準備新的版本，將修正剛 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 腳本，以便首先宣告這些函式採用 internal 類型。（腳本修復將成為即將發布版本的一部分，因此您可以等待這些版本。）
我謹代表 PostgreSQL 核心委員會，對於這些錯誤可能引起的任何問題表示歉意。
此致，tom lane
此文章已從 PostgreSQL 網站的先前版本遷移。對於遷移造成的任何格式問題，我們深感抱歉。