このリリースは 11.2 からの修正リリース(2019年5月9日リリース)です。
11.x からのアップデートではダンプ、リストアは不要です。
11.1より前のバージョンからのアップデートの場合には 11.1 のリリース情報も確認してください。
PostgreSQL 11.2 から 11.3 への変更点
11.3、10.8、9.6.13、9.5.17、9.4.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。
- 行単位セキュリティポリシーが、プランナの選択性見積り処理を通して、すり抜けされてしまうことがあり、防止されました。(CVE-2019-10130) (Dean Rasheed) (11)(10)(9.6)(9.5)
- パーティション振り分けのエラーを報告する際に解放済みメモリへのアクセスを回避するように修正されました。(CVE-2019-10129) (Michael Paquier) (11)
- パーティションテーブルに対する ALTER TABLE がインデックス再利用可能と判断した場合にシステムテーブルのデータが破損することがあり、修正されました。 (Amit Langote, Tom Lane) (11)
- 単文のトランザクションで ON COMMIT DROP と IDENTITY列を伴う一時テーブルが作られたときにシステムテーブルのデータが破損する障害があり、修正されました。 (Peter Eisentraut) (11)(10)
- パーティションテーブルが属するパーティション(子テーブル)以上に削除された列を含む場合に、ALTER INDEX ... ATTACH PARTITION がエラーになる動作が修正されました。 (Álvaro Herrera) (11)
- パーティションの既存インデックスを、新たに作成されたパーティションインデックス(親テーブルのインデックス)にアタッチするときのエラーが修正されました。 (Amit Langote, Álvaro Herrera) (11)
- パーティション化された問い合わせ結果に対して他セッションによる更新を反映させる処理で、バックエンドプロセスのクラッシュが回避されました。 (Amit Langote) (11)(10)
- 削除された属性を持つ複数階層のパーティションテーブルでの、行の振り分けが修正されました。 (Amit Langote, Michael Paquier) (11)
- 外部キー制約の初期検査の slow-path処理がパーティションテーブルに適用されるときの失敗が修正されました。 (Hadi Moshayedi, Tom Lane, Andres Freund) (11)
- 継承ツリーやパーティションテーブルの全てのテーブルが除外されうるUPADTE や DELETE の振る舞いが修正されました。 (Amit Langote, Tom Lane) (11)(10)(9.6)(9.5)(9.4)
- constraint_exclusion = on でパーティションに直接アクセスするとき、除外のための CHECK制約と同様に各パーティションのパーティション制約を使用するようになりました。 (Amit Langote, Tom Lane) (11)
- トランザクションコミットをまたがるようにカーソル問い合わせを永続化しようとしてエラーが生じたときのクラッシュが回避されました。 (Tom Lane) (11)
- ロジカルレプリケーションにおける FOR ALL TABLES指定のパブリケーションが存在するときに、一時テーブルとUNLOGGEDテーブルの更新に対する不正なエラー発行が修正されました。 (Peter Eisentraut) (11)(10)
- 更新可能ビューに複数行を挿入する INSERT ... VALUESコマンドでの明示的なデフォルト要素の処理が修正されました。 (Amit Langote, Dean Rasheed) (11)(10)(9.6)(9.5)(9.4)
- CREATE VIEW がゼロ列ビューを作れるように修正されました。 (Ashutosh Sharma) (11)(10)(9.6)(9.5)(9.4)
- 欠けていた CREATE TABLE IF NOT EXISTS ... AS EXECUTE ... 構文が追加されました。 (Andreas Karlsson) (11)(10)(9.6)(9.5)
- 行単位セキュリティポリシーの式に現れる副問い合わせが、確実に正しいユーザ権限で実行されるようになりました。 (Dean Rasheed) (11)(10)(9.6)(9.5)
- SQL:2006 以降の要件に基づき、xmloption = content が設定されているとき、xml型の有効な値としてXMLドキュメントを受け入れるようになりました。 (Chapman Flack) (11)(10)(9.6)(9.5)(9.4)
- サーバ起動時の既存共有メモリセグメントが未だ使われているかどうかの検査が改善されました。 (Noah Misch) (11)(10)(9.6)(9.5)(9.4)
- BtreeインデックスのVACUUM で、起こりうるゼロ除算が回避されました。 (Piotr Stefaniak, Alexander Korotkov) (11)
- パラレルワーカのトランザクションを別々のトランザクションと数えないように修正されました。 (Haribabu Kommi) (11)(10)(9.6)
- GINインデックスのWALレコードにおける非互換性が修正されました。 (Alexander Korotkov) (11)(10)(9.6)(9.5)(9.4)
- レプリケーション接続で SHOWコマンドを実行する時に起こりうるwal senderプロセスのクラッシュが修正されました。 (Michael Paquier) (11)(10)
- ポータルから少しずつ行を取得するときのバックエンドプロセスのメモリリークが回避されました。 (Tom Lane) (11)
- パーティションのリレーションキャッシュ項目が再作成されるときのメモリリークが回避されました。 (Amit Langote, Tom Lane) (11)(10)
- fsync や sync_file_range を呼ぶときに、適切な箇所において、INVAL および ENOSYS のエラーに寛容になりました。 (Thomas Munro, James Sewell) (11)(10)(9.6)(9.5)(9.4)
- autovacuum の pg_stat_activity 表示で、BRIN の要約操作中に正しいリレーション名を報告するようになりました。 (Álvaro Herrera) (11)(10)
- GEQO が有効なときにパーティションの関する結合プランを作成しようとしたときのバックエンドプロセスのクラッシュが回避されました。 (Tom Lane) (11)
- プランナで FULL外部結合からのラテラル参照があるときに「ERROR: failed to build any N-way joins」エラーが発生していたものが修正されました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)
- 複数行を返す関数を空と推定されるリレーションに適用する問い合わせに対する誤ったプラン作成が修正されました。 (Tom Lane, Julien Rouhaud) (11)(10)
- 漏洩のある演算子で pg_statistic のデータを参照させる際のルールを強制するときに、適切なユーザ権限を検査するようになりました。 (Dean Rasheed) (11)(10)(9.6)(9.5)(9.4)
- グルーピングをする問い合わせでプランナの並列安全性の検査が修正されました。 (Etsuro Fujita) (11)
- プランナのユニークインデックスのロジックにおいて、INCLUDEで含められたインデックス列の誤った処理が修正されました。 (Tom Lane) (11)
- 配列の型キャスト式に対する誤った STRICT の検査が修正されました。 (Tom Lane) (11)
- 多数のイコール条件と多数の潜在的に関連のある外部キー制約があるときのプラン作成が高速化されました。 (David Rowley) (11)(10)(9.6)
- 多数のテーブルを作成したトランザクションをロールバックするときに、テーブル数に対して O(N^2)オーダで処理を要する性能問題が回避されました。 (Tomas Vondra) (11)(10)(9.6)(9.5)(9.4)
- 動的共有メモリの割り当てで、稀な場合におきるバックエンドプロセスのクラッシュが修正されました。 (Thomas Munro, Robert Haas) (11)(10)
- 動的共有メモリの管理での競合状態を修正しました。 (Thomas Munro) (11)(10)(9.6)(9.5)(9.4)
- ホットスタンバイのPostgreSQLマスタプロセス(postmaster)が、スマートシャットダウン要求を受け取った後でシャットダウンに失敗する可能性がある競合状態が修正されました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)
- pg_identify_object_as_address()に不正な入力が与えられたとき、クラッシュを起こす可能性があり、修正されました。 (Álvaro Herrera) (11)(10)(9.6)(9.5)
- txid_status() でトランザクション失敗の状態にアクセスできない可能性があり、修正されました。 (Thomas Munro) (11)(10)
- OpenSSLライブラリのバージョンが混在した状態でSCRAM認証を使用しようとしたときの認証失敗が修正されました。 (Michael Paquier, Peter Eisentraut) (11)
- 暗号化された SCRAM-SHA-256 および MD5 パスワードの検証が強化されました。 (Jonathan Katz) (11)(10)(9.6)(9.5)(9.4)
- データベースのエンコーディングとは異なるエンコーディングが指定されたlc_time設定の処理が修正されました。 (Juan José Santamaría Flecha, Tom Lane) (11)(10)(9.6)(9.5)(9.4)
- サーバのデータディレクトリ内のほかのファイルと同じ権限でcurrent_logfilesファイルが作成されるようになりました。 (Haribabu Kommi) (11)
- 単項マイナス演算子を含む場合について、operator_precedence_warning設定に基づくチェックの誤動作が修正されました。 (Rikard Falkeborn) (11)(10)(9.6)(9.5)
- 浮動小数点のサーバパラメータ値として「NaN」が拒否されるようになりました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)
- pg_class の各インデックスを再作成するときにアサート失敗を回避するために、REINDEX処理を並び替えて行うようになりました。 (Andres Freund, Tom Lane) (11)(10)(9.6)(9.5)(9.4)
- パラメータ化されたダミーパスに対するプランナのアサート失敗が修正されました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)
- SnapBuildInitialSnapshot() の結果に正しいテスト関数が挿入されるようになりました。 (Antonin Houska) (11)(10)(9.6)(9.5)(9.4)
- Windows で断続的に「could not reattach to shared memory (共有メモリに再接続できなかった)」としてセッションの起動に失敗する不具合が修正されました。 (Noah Misch) (11)(10)(9.6)(9.5)(9.4)
- Windows上のディレクトリスキャンにおけるエラー検出が修正されました。 (Konstantin Knizhnik) (11)(10)(9.6)(9.5)(9.4)
- ecpg の文法問題を修正しました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)
- CREATE TABLE AS に対する ecpg の構文がサーバのものに同期されました。 (Daisuke Higuchi) (11)(10)(9.6)(9.5)
- ecpg のインクルードファイル名の処理によるバッファオーバーランの可能性があり、修正されました。 (Liu Huailing, Fei Wu) (11)(10)(9.6)(9.5)(9.4)
- ターゲットデータディレクトリ内の一時ファイルが削除できなかったためにpg_rewind が失敗していた不具合が修正されました。 (Michael Paquier) (11)
- 指定されたデータディレクトリが正しい PostgreSQLバージョンであることをpg_verify_checksums が確認するようになりました。 (Michael Paquier) (11)
- リモート側でグループ化または集約を使用しているクエリに無相関の副SELECT、外部参照、またはパラメータシンボルである SELECT の選択リスト項目があってもcontrib/postgres_fdw がクラッシュしなくなりました。 (Tom Lane) (11)(10)
- 振り分けられた行を挿入するために選択されたリモートパーティションが、同一コマンドで後で更新される UPDATEサブプランの対象である場合にエラーを報告するように contrib/postgres_fdw が変更されました。 (Amit Langote, Etsuro Fujita) (11)
- contrib/pg_prewarm でプレウォームが何らかの理由で失敗してもバックグラウンドワーカプロセスが無制限に respawnしなくなりました。 (Mithun Cy) (11)
- lo_unlink()呼び出しが失敗した場合に contrib/vacuumlo がクラッシュしなくなりました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)
- タイムゾーンライブラリのコピーが IANA tzcode release 2019a と同期されました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)
- タイムゾーンデータファイルが tzdata release 2019a に更新されました。パレスチナとメトラカトラの夏時間法の変更とイスラエルの歴史的な修正が含まれます。 (11)(10)(9.6)(9.5)(9.4)
一部のプランナの選択性見積り処理ではプランナ統計情報(pg_statistic の 最頻値など)で見つかった値にユーザ定義演算子を適用します。そのため、実行したユーザにその列を参照する権限がなくとも、漏洩のある演算子が一部行の列データ値を露出させることができます。9.6.3、9.5.7、9.4.12、9.3.17、9.2.21 での CVE-2017-7484 セキュリティ障害の修正で同様の問題に対する対処が行われていましたが、行単位セキュリティについては対応されていませんでした。
本修正により、漏洩のある(LEAKPROOF属性が真でない)演算子は関連する行単位セキュリティ(RLS)ポリシーが無い場合に限ってプランナ統計情報に適用が許されるようになります。
この障害はクラッシュをひき起こします。また、原理的にはサーバメモリ内容を露出させる攻撃に利用できる可能性があります。なお、上記のパーティション振り分けのエラーとは以下の類です。
db=# CREATE TABLE parted_tbl (id int, v text) PARTITION BY RANGE (id); db=# CREATE TABLE part1 PARTITION OF parted_tbl FOR VALUES FROM (1) TO (100); db=# INSERT INTO parted_tbl VALUES (105, 'XX'); ERROR: no partition of relation "parted_tbl" found for row DETAIL: Partition key of the failing row contains (id) = (105).
例えば、ALTER TABLE .. ALTER COLUMN TYPE 実行時に物理テーブルの書き換えは不要と判断したケースで発生します。ALTER TABLE を行って定義情報の破損が生じたパーティションテーブルを、次に DROP したときにバックエンドプロセスがクラッシュ終了する動作が報告されました。
以下のような発生例が報告されました。
(あるセッションで以下のように一時テーブルを作った後、) db=# CREATE TEMP TABLE t4 (c int GENERATED BY DEFAULT AS IDENTITY) ON COMMIT DROP; (別セッションで別の一時テーブルを作ろうとした際に不明なエラーが出る) db=# CREATE TEMPORARY TABLE t4_2 (d text); ERROR: could not open relation with OID 16345
これにより pg_upgrade を失敗させる可能性もあります。以下の予期せぬエラーが発生します。
ERROR: incorrect attribute map
この障害は、アタッチ後に実行する当該パーティションインデックスを使う DDL で以下のような予期せぬエラーを発生させます。
ERROR: index ... not found in partition ...
これは、READ COMMITTED 隔離レベルを使用していて、他のセッションが問い合わせの対象行を同時並行に更新していた場合にEPQ(EvalPlanQual)の再チェック処理で発生します。
パーティションテーブルに列削除が行われていた場合に INSERT 実行に対して、以下の予期せぬエラーが発生する場合がありました。
ERROR: cannot extract attribute from empty tuple slot SQL state: XX000
(権限の問題などで)fast-path処理が使えない場合という、一般的でない場合以外では、この問題は顕在化しません。fast-path、slow-path は検査処理実装の内部的な区別です。前者が使えない場合に後者が使われます。
以下のようなエラー発生が報告されました。
db=# CREATE ROLE test_role WITH LOGIN; db=# CREATE TABLE t9_ref(a int PRIMARY KEY); db=# GRANT REFERENCES ON t9_ref TO test_role; db=# SET ROLE test_role; db=> CREATE TABLE t9(a int, b int) PARTITION BY LIST (a); db=> ALTER TABLE t9 ADD CONSTRAINT t9_b_key FOREIGN KEY (b) REFERENCES t9_ref(a); ERROR: could not open file "base/16432/49876": No such file or directory
このような場合、RETURNING句があっても問い合わせが正しい列セットを報告せず、文レベルトリガがあっても実行されませんでした。
(障害動作例: WHERE false の場合の RETURNING句の応答は列が無く不正) db=# CREATE TABLE t10 (a int, b int); db=# CREATE TABLE t10c () inherits (t10); db=# INSERT INTO t10c VALUES (1,2); db=# UPDATE t10 SET a = a + 1 WHERE false RETURNING b, a; -- (0 rows) UPDATE 0 db1=# UPDATE t10 SET a = a + 1 WHERE true RETURNING b, a; b | a ---+--- 2 | 2 (1 row) UPDATE 1
この変更は 10.xバージョンの振る舞いに戻したことになります。
db=# CREATE TABLE t11p (a int) PARTITION BY LIST (a); db=# CREATE TABLE t11c PARTITION OF t11p FOR VALUES IN (1); db=# SET constraint_exclusion TO on; db=# EXPLAIN SELECT * FROM t11c WHERE a = 2; (修正前の結果、範囲外の値でもテーブルスキャンが発生) QUERY PLAN ---------------------------------------------------- Seq Scan on t11c (cost=0.00..41.88 rows=13 width=4) Filter: (a = 2) (2 rows) (本来期待される結果) QUERY PLAN ------------------------------------------ Result (cost=0.00..0.00 rows=0 width=4) One-Time Filter: false (2 rows)
プロシージャがオープンされた明示的あるいは暗黙的なカーソル(PL/pgSQLのFORループ問い合わせなど)を持つときにコミットしようとした場合、カーソルはコミット前に完全に実行され結果を保存して以降で利用可能にします。このような処理の中でエラーが生じた場合にバックエンドプロセスのクラッシュが起こっていました。
このようなテーブルはパブリケーション用には無視されるべきでしたが、一部コードでそうなっていませんでした。
以下例のように複数行を同時に挿入した場合、ビューにデフォルト値が無い列で元テーブルのデフォルト値ではなく NULL が使われてしまいます。
(障害動作発生例: a=14 の行と a=15,16 の行で振る舞いが違う) db=# CREATE TABLE t14 (a int, b text default 'Table default', c text default 'Table default', d text, e text); db=# CREATE VIEW v14 AS SELECT * FROM t14 db=# ALTER VIEW v14 ALTER b SET DEFAULT 'View default'; db=# ALTER VIEW v14 ALTER d SET DEFAULT 'View default'; db=# INSERT INTO v14 VALUES (14, default, default, default, default); db=# INSERT INTO v14 VALUES (15, default, default, default, default), (16, default, default, default, default); db=# SELECT * FROM t14; a | b | c | d | e ----+--------------+---------------+--------------+--- 14 | View default | Table default | View default | 15 | View default | | View default | 16 | View default | | View default | (3 rows)
これによりゼロ列テーブルが作成可能であることと一貫性を持ち、テーブルをビューで置き換える際に失敗するケースを回避できます。
db=# CREATE TABLE t15 (id int primary key, v text); db=# CREATE TABLE t15_0 (); db=# CREATE VIEW v15 AS SELECT FROM t15; db=# CREATE VIEW v15_0 AS SELECT * FROM t15_0; (修正前バージョンでは上記両CREATE VIEVで以下のエラーが出ました) ERROR: view must have at least one column
AS の後に問い合わせにプリペアド文を実行する EXECUTE文を記述することは可能であるべきでしたが対応していませんでした。
これまで、行単位セキュリティ(RLS)ポリシーを持つテーブルがビューを通してアクセスされる場合に、セキュリティ検査がビューを呼び出したユーザで行われ、ビュー所有者ユーザで行われませんでした。後者が本来の正しい動作です。
これまでは PostgreSQL は SQL:2003 の定義に従っていて、このような場合にはデータを受け入れませんでした。しかし、ダンプ/リストアで全ての有効なXMLデータを受け入れる xmloption の設定値が無いという重大な問題が問題が生じることから、SQL:2006 の定義に変更されました。
加えて、確実にダンプ/リストアできるように pg_dump が SET xmloption = contentを出力するようになりました。
PostgreSQLのマスタプロセス(postmaster)は、たとえ postmaster.pid ファイルが削除されていても、以前の postmasterから生じた実行中プロセスが無いかを調べるようになりました。
これにより PostgreSQL二重起動によるデータ破損を予防します。
これは vacuum_cleanup_index_scale_factor 設定値に基づいてインデックスのクリーンアップが必要かどうかについて不正確な判断をひき起こします。
パラレル問い合わせ実行があるときに、実行時統計情報のトランザクション数が本来より多く計数されていました。
前回のマイナーリリースには後方互換性に問題がありました。ストリーミングレプリケーション等で更に以前のマイナーバージョンが生成したWAL を適用する場合にロック処理の問題からハングアップする動作が報告されました。
本修正で WALレコードを適用する際に、前マイナーリリースの修正があるWALレコードも、無いレコードも両方読めるように修正されました。
特に JDBCで問い合わせ結果を1行ずつ取得する場合に顕在化します。
このメモリリークはセッション内で継続します。
ファイル同期に失敗が生じたなら PANIC とする前回リリースでの変更は、失敗が想定できて本質的に操作がサポートされないことによる場合については、過度に偏執的でした。
例えば Windows Subsystem for Linux において sync_file_range がサポートされないために PANIC が起きていました。
以前は誤ってデータベース名が報告されていました。
(エラー発生例) db=# SELECT * FROM (VALUES (1),(2)) v1(r1) LEFT JOIN LATERAL ( SELECT * FROM generate_series(1, v1.r1) AS gs1 LEFT JOIN LATERAL ( SELECT * FROM generate_series(1, gs1) AS gs2 LEFT JOIN generate_series(1, gs2) AS gs3 ON TRUE ) AS ss1 ON TRUE FULL JOIN generate_series(1, v1.r1) AS gs4 ON FALSE ) AS ss0 ON TRUE; ERROR: failed to build any 3-way joins
この障害により、10.x バージョンでは僅かに非効率なプランが生成されるだけですが、11.x バージョンでは「ERROR: set-valued function called in context that cannot accept a set 」エラーをひき起こす可能性があります。
元となるテーブルにビューを通してアクセスするとき、漏洩のある演算子をテーブルの統計データに適用して良いかの判断に、問い合わせを実行するユーザの権限ではなく、ビュー所有者の権限を考慮するようになりました。これにより、プランナのどのデータが可視かのルールをエグゼキュータのルールと一致させて、劣ったプランを回避します。
これまでは、並列化されている可能性のある対象リストを評価する動作が無いかもしれませんでした。この問題によりプランの劣化が発生していました。
本障害により、含められた列を持つユニークインデックスが問い合わせ結果の唯一性を保証することをプランナが認識しなくなる可能性があり、プランの劣化がもたらされました。
以下例のように STRICT を指定した SQL関数に NULL を渡しても、応答が NULL にならない動作が発生していました。
db=# CREATE TABLE t34 (c1 int); db=# INSERT INTO t34 VALUES (1), (NULL); db=# CREATE FUNCTION f34 (int) RETURNS int[] LANGUAGE sql AS $$ SELECT array[0, $1]::bigint[]::int[] $$ STRICT; db=# SELECT f34(c1) FROM t34; (修正前の応答) f34 ---------- {0,1} {0,NULL} (2 rows) (正しい応答、2番目は NULL が返る) f34 ------- {0,1} (2 rows)
これにより「ERROR: dsa_area could not attach to segment」や「ERROR: cannot unpin a segment that is not pinned」のエラーが生じる可能性がありました。
pg_identify_object_as_address() はシステム情報を取得するSQL関数の一つです。
以前は未来のトランザクションの状態を取得し続けると、最終的に以下のようなエラーが発生していました。
=# SELECT txid_status(txid_current() + 1); ERROR: could not access status of transaction 32768 DETAIL: Could not read from file "pg_xact/0000" at offset 8192: No error: 0.
サーバが OpenSSL 1.0.2 以降を使用しているときに libpq がOpenSSL 1.0.1 以前を使用していると、どの SASL機構を使用するかのネゴシエーションが失敗し、「ERROR: channel binding not supported by this build」という分かりにくいエラーメッセージが発生していました。
一致する先頭文字をもつパスワード文字列が SCRAM-SHA-256 または MD5形式に正しくハッシュ化されたものと間違われる可能性がありました。
SCRAM-SHA-256形式では先頭が SCRAM-SHA-256$ であるかのみをチェックし、フィールドはチェックしておらず、MD5 形式では先頭が md5 であるかと長さのみをチェックし、16進数の文字であるかはチェックしていませんでした。パスワードは受け入れられますが、あとで使用できなくなります。
ASCII 以外の文字を含むローカライズされた月または日の名前は、以前は予期せぬエラーまたはそのロケールで誤った出力を発生させていました。
以前は log_file_mode で指定された権限を使用していましたが、バックアップユーティリティに問題を発生させる可能性がありました。
以前は以下のような警告が発生していました。
db=# SET operator_precedence_warning TO on; db=# SELECT -random() IS NULL; WARNING: operator precedence change: IS is now lower precedence than - row 1: SELECT -random() IS NULL; ^ ?column? ---------- f (1 row)
=# SET random_page_cost TO 'NaN'; ERROR: parameter "random_page_cost" requires a numeric value
アサートを無効にしたビルドでは本障害によるユーザに見える影響はありません。
コアコードでは考慮する必要はありませんが、いくつかの拡張ではその必要があります。SnapBuildInitialSnapshot() は主としてロジカルレプリケーションのために使われる内部実装関数です。
これまで認識されていなかった不具合の原因は、プロセスのデフォルトスレッドプール用のスレッドスタックの作成です。そのようなスタックが異なるメモリ領域に割り当てられるようになりました。
ディレクトリの読み取り権限がない、といったエラーが検出されないか正しく報告されず、そのかわりにディレクトリが空であるかのように静かに振る舞っていました。
ecpg プログラムでセミコロンが欠けているとき(「SET variable TO DEFAULT」でなく)「SET variable = DEFAULT」の誤変換をひき起こし、サーバに拒否されるであろう誤った構文を出力しました。さらに、複数の型名を列挙した DROP TYPE または DROP DOMAIN コマンドは、実際には最初の型名だけが処理されていました。
以前は、このような状況が原因でサーバーがクラッシュしたり、UPDATE結果が不正確になったりしていました。
これによって Africa/Casablancaゾーンで 2440年の標準時とサマータイムの誤った遷移が出力されるという zic の小さな不具合が修正されます。また、zic に新しい -r オプションが追加されます。
Etc/UCT は Etc/UTC への後方互換性のあるリンクになりました。現在は一般的にタイプミスとされる略語の UCT を生成する別のゾーンではありません。PostgreSQL は依然としてゾーンの省略形として UCT の入力を受け入れますが、それを出力しません。