1. /
  2. /
  3. PostgreSQL 9.1.23 に関する技術情報

PostgreSQL 9.1.23 に関する技術情報

このリリースは 9.1.22 からの修正リリース（2016年8月11日リリース）です。

9.1.x からのアップデートではダンプ、リストアは不要です。

また、9.1.16 より前のバージョンからアップデートを行う場合は 9.1.16 に関する技術情報 を参照してください。

PostgreSQL 9.1.22 から 9.1.23 への変更点

9.5.4、9.4.9、9.3.14、9.2.18、9.1.23 の各バージョンが同時にリリースされており、 本ページでは共通の記載としています。 各修正項目が適用されるバージョン系列番号を 項目末尾に括弧書きで記載しています。

  1. 入れ子になった CASE-WHEN式の誤評価のおそれがあり、修正されました。 (Heikki Linnakangas, Michael Paquier, Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)

    2. 他の CASE のテスト値の副式としてあらわれる CASE式では、自身のテスト値が null かどうかを誤ることがありました。

    CASE式で使用される等価演算子を実装する SQL関数のインライン化により、そのSQL関数内で CASE式で呼ばれた関数に誤ったテスト値を渡すおそれがありました。テスト値が異なるデータ型である場合、クラッシュするかもしれず、更には、一部サーバメモリを露出させるために悪用されるかもしれません。これは CVE-2016-5423 として登録されています。

    以下例は、副CASE式で 'it was bar!' になり、返し値は 'bar recognized'になるのが正しい動作です。 

    (入れ子CASEの障害動作例)

db=# CREATE FUNCTION vol(text) RETURNS text AS
       'begin return $1; end' LANGUAGE PLPGSQL VOLATILE;

db=# SELECT CASE
     (CASE vol('bar') WHEN 'foo' THEN 'it was foo!'
                      WHEN vol(null) THEN 'null input'
                      WHEN 'bar' THEN 'it was bar!' END)
     WHEN 'it was foo!' THEN 'foo recognized'
     WHEN 'it was bar!' THEN 'bar recognized'
     ELSE 'unrecognized' END;

     case
--------------
 unrecognized
(1 row)

    以下例は 'is not foo' が返るのが正しい動作です。定義した =演算子と inline_eq関数は、最後の SELECT文の CASE式を通して実行されます。 

    (インライン関数の = 演算子の障害動作例)

db=# CREATE DOMAIN foodomain AS text;
db=# CREATE FUNCTION volfoo(text) RETURNS foodomain AS
       'begin return $1::foodomain; end' LANGUAGE plpgsql VOLATILE;
db=# CREATE FUNCTION inline_eq(foodomain, foodomain) RETURNS boolean AS
       'SELECT CASE $2::text WHEN $1::text THEN true ELSE false END'
       LANGUAGE sql;
db=# CREATE OPERATOR = (procedure = inline_eq,
       leftarg = foodomain, rightarg = foodomain);

db=# SELECT CASE volfoo('bar')
            WHEN 'foo'::foodomain THEN 'is foo' ELSE 'is not foo' END;
  case
--------
 is foo
(1 row)
  2. クライアントプログラムにおけるデータベース名とロール名に含まれる特殊文字の扱いが修正されました。 (Noah Misch, Nathan Bossart, Michael Paquier) (9.5)(9.4)(9.3)(9.2)(9.1)

    3. 多くのクライアントプログラムが、データベース名やロール名が "（ダブルクオート）や （バックスラッシュ）を含むことで、混乱をきたすことがありえました。

    psql の connect と password において、2つ組のダブルクオートの扱いがドキュメント通りになるように修正されました。

    さらに、psql の connect コマンドに -reuse-previous オプションが導入され、以前の接続のパラメータを再利用するかの明示的な制御ができるようになりました。従来はデータベース名が接続文字列のように見えるかで選択されていました。これは pg_dumpall で特殊文字を含むデータベース名の安全な処理を可能にします。

    pg_dumpall は、改行文字(CR、LF)を含むデータベース名・ロール名の処理を拒絶するようになりました。将来はサーバ側でもこのような名前を拒絶するかもしれません。

    作りこんだ特殊文字を含むオブジェクト名が、次に pg_dumpall や他のメンテナンス操作をするときにスーパーユーザ権限でコマンドを実行させるのに用いられるかもしれないため、これらはセキュリティ修正とみなされます。本件は CVE-2016-5424 として登録されています。

  3. 入れ子の複合値に適用される IS NULL、IS NOT NULL の誤動作が修正されました。 (Andrew Gierth, Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)

    4. SQL標準では IS NULL は全ての要素が NULL である行値には TRUE を返すべきとしていますが、これは再帰的に適用することを意味しません。 

    (IS NULL のSQL標準仕様)
 ROW(NULL,NULL) IS NULL             → TRUE
 ROW(NULL, ROW(NULL, NULL)) IS NULL → FALSE

    PostgreSQL のエグゼキュータは上記の通りに作られていますが、プランナ最適化が働いて、以下のような誤った結果が生じていました。 

    (誤動作の例 - プラン時点で ROW(NULL,NULL) に置換済み)

=# EXPLAIN (VERBOSE) SELECT ROW(NULL, ROW(NULL, NULL)) IS NULL;
                      QUERY PLAN
-------------------------------------------------------
 Result  (cost=0.00..0.01 rows=1 width=0)
   Output: (ROW(NULL::unknown, NULL::unknown) IS NULL)
(2 rows)

=# SELECT ROW(NULL, ROW(NULL, NULL)) IS NULL;
 ?column?
----------
 t

    postgres_fdw によるリモート問い合わせでも同様の問題があり、修正されました。

  4. 再帰 CTE (WITH RECURSIVE) 内で INSERT ... ON CONFLICT 構文を使うと、unrecognized node type エラーが出るのが修正されました。 (Peter Geoghegan) (9.5)

    5. 以下のようにエラーが発生していました。 

    db=# CREATE TABLE foobar (id text PRIMARY KEY);

db=# WITH RECURSIVE upserted AS (
       INSERT INTO foobar (id) VALUES ('a')
       ON CONFLICT (id) DO NOTHING
       RETURNING id
       ) SELECT id FROM upserted;
ERROR:  XX000: unrecognized node type: 920
  5. INSERT ... ON CONFLICT が、プランナの式の前処理フェーズで単純化されたインデックス式やインデックス述語を正常に照合するように修正されました。 (Tom Lane) (9.5)

    6. 以下のような場合に、ON CONFLICT の conflict_target に対応したユニークインデックスや排他制約が無いと見なされて、エラーが発生していました。障害発生はデータ型や書き方に依存します。下記例では、bigint型のところがint型であれば、あるいは、0 を '0'::bigint と記述していれば発生しません。 

    db=# CREATE TABLE t5 (a bigint, b bigint);

db=# CREATE UNIQUE INDEX ON t5 (coalesce(a, 0), coalesce(b, 0));

db=# INSERT INTO t5 VALUES (1, 2)
       ON CONFLICT ((coalesce(a, 0)), (coalesce(b, 0))) DO NOTHING;
ERROR:  there is no unique or exclusion constraint matching the ON CONFLICT specification
  6. INSERT ... ON CONFLICT命令で、ON CONSTRAINT で指定されていない方の排他制約に違反した場合の処理が修正されました。 (Tom Lane) (9.5)

    7. 以下例のような場合が該当します。通常の制約違反になるのが正しい動作ですが、無限ループに入ってしまいます。 

    (エラー例)
db=# CREATE TABLE t6 (f1 int UNIQUE, f2 box, EXCLUDE USING gist(f2 WITH &&));
db=# INSERT INTO t6 VALUES (1, '((0,0),(1,1))');
INSERT 0 1

db=# INSERT INTO t6 VALUES (2, '((0,0),(1,2))')
       ON CONFLICT ON CONSTRAINT t6_f1_key DO NOTHING;
  → f2 の方の制約違反なのでエラーになるのが正しいが、無限ループで応答しない
  7. INSERT ... ON CONFLICT が、対象テーブルが OID カラムにユニークインデックスを持っていた場合に失敗しないようになりました。 (Tom Lane) (9.5)

    8. これまでは該当の場合には、OIDカラムの制約に関係があっても無くても、INSERT ... ON CONFLICT が使用できませんでした。以下のようにエラーが発生します。 

    db=# CREATE TABLE t7 (id int UNIQUE) WITH """"OIDS;
db"""" =# CREATE UNIQUE INDEX ON t7 (oid);

db=# INSERT INTO t7 VALUES (1) ON CONFLICT (id) DO NOTHING;
ERROR:  system column in index

db=# INSERT INTO t7 VALUES (1) ON CONFLICT (oid) DO NOTHING;
ERROR:  system columns cannot be used in an ON CONFLICT clause
  8. inet型、cidr型がコロン区切りフィールドが多すぎる IPv6アドレスを正しく拒絶するようになりました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)

    9. IPv6アドレスの表記は 128ビットを 16ビットごとにコロン(:)で区切るので最大でもコロンは 7つです。また、「::」が使えるのは一か所だけです。これら規則に違反してもエラーにならず「::/0」と解釈される場合がありました。 

    (誤動作の例)

db=# SELECT '99:99:99:99::99:99:99:99:99:99'::inet;
 inet
------
 ::/0
(1 row)

db=# SELECT '99:99:99:99::99:99:99:1::/118'::cidr;
 cidr
------
 ::/0
(1 row)
  9. point ## lseg 演算子の実装である close_ps() 関数が NaN値を含む入力座標でクラッシュしてしまうのが防止されました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)

    10. 上記演算子は右辺要素内の左辺要素への近接点を返すものです。これまでクラッシュしていたケースでは NULL が返るようになります。 

    (演算子の通常動作とクラッシュ例)

=# SELECT '(1.5,1.5)'::point ## '(0,0),(0,3)'::lseg;
 ?column?
----------
 (0,1.5)
(1 row)

=# SELECT 'NaN,NaN'::point ## '(Nan,0),(0,NaN)'::lseg;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
  10. 一貫性に欠けた値が渡された場合に pg_get_expr() 関数がクラッシュする可能性が回避されました。 (Michael Paquier, Thomas Munro) (9.5)(9.4)(9.3)

    11. 以下の障害例が報告されました。 

    db=# CREATE TABLE t10 (id int primary key, c1 int NOT NULL, c2 int);
db=# CREATE INDEX idx10 ON t10 (c1) WHERE (c2 = 100);

db=# SELECT pg_get_expr(i.indpred, i.indexrelid) FROM pg_index i;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

    pg_get_expr() は pg_dump やシステムビュー定義内で使われる関数であって、アプリケーションやデータベース管理者が直接使うことはほとんどありません。

  11. to_number() で幾つかの 1バイトのバッファ超過読み込みが修正されました。 (Peter Eisentraut) (9.5)(9.4)(9.3)(9.2)(9.1)

    12. 幾つかの場合に to_number() 関数が入力文字列から1文字多く読み取りしていました。入力データがメモリ末尾に隣接している場合には、僅かながらクラッシュの可能性があります。

  12. WITH NO DATA が指定されたときには、CREATE MATERIALIZED VIEW またはCREATE TABLE AS に含まれている問い合わせに対して プランナを実行しないようになりました。 (Michael Paquier, Tom Lane) (9.5)(9.4)(9.3)

    13. これは不要なエラー状況を回避します。例えば、STABLE な関数が参照するテーブルがマテリアライズドビューを作成した時点では未だ無い、といった場合です。

  13. heap_update() を通る高コストパスにおいて、安全でない中間状態を回避するようになりました。 (Masahiko Sawada, Andres Freund) (9.5)(9.4)(9.3)(9.2)(9.1)

    14. これまで該当ケースにおいては、XMAX をセットして対象タプルをロックするけれど、その操作を WAL書き出しをしませんでした。そのため、ページ変更がバッファ溢れでディスクに書かれて、続いてタプル更新が完了する前にクラッシュが生じると、データ不整合の危険がありました。

  14. 行ロック操作の WALリプレイでのヒントビット更新が修正されました。 (Andres Freund) (9.5)(9.4)(9.3)

    15. 本障害の影響として、コミット前の準備されたトランザクションにより保持された行ロックがクラッシュ後の再起動で適用に失敗するおそれがあることが知られています。

  15. SERIALIZABLE または REPEATABLE READモードで SELECT ... FOR KEY SHARE による行ロックを取得するときに、不要な直列化失敗エラーの発生を回避するようになりました。 (Álvaro Herrera) (9.5)(9.4)(9.3)

    16. FOR KEY SHARE 行ロックは外部キー制約を持つテーブルの更新で暗黙に取得されます。以下の場合にエラーが発生していましたが、修正後は発生しなくなります。 

    (テスト用のテーブルを作成)
db=# CREATE TABLE t15a (id int PRIMARY KEY, uid int, name text);
db=# CREATE TABLE t15b (id int PRIMARY KEY, d date);
db=# ALTER TABLE t15a ADD FOREIGN KEY (uid) REFERENCES t15b (id);
db=# INSERT INTO t15b VALUES (1, now());
db=# INSERT INTO t15a VALUES (1, 1, 'one');

(セッションその1)
db=# START TRANSACTION ISOLATION LEVEL REPEATABLE READ;
db=# UPDATE t15a SET name = 'update1', uid = 1 WHERE id = 1;

                      (セッションその2)
                      db=# START TRANSACTION ISOLATION LEVEL REPEATABLE READ;
                      db=# UPDATE t15b SET d = now() WHERE id = 1;
                      db=# COMMIT;

db=# UPDATE t15a SET name = 'update2', uid = 1 WHERE id = 1;
ERROR:  could not serialize access due to concurrent update
CONTEXT:  SQL statement "SELECT 1 FROM ONLY "public"."t15b" x WHERE "id" OPERATOR(pg_catalog.=) $1 FOR KEY SHARE OF x"
  16. エグゼキュータにおいて、拡張されたデータムがプランノードから返るとき、それが確実にリードオンリーであるように修正されました。 (Tom Lane) (9.5)

    17. データム(Datum)とは SQLデータ型の値の受け渡しに使われる実装内部データ型です。本修正で、下位プランノードの結果が上位ノードの複数個所で参照される場合に、失敗するのを回避します。PostgreSQL本体に関する限り PL/pgSQL関数から返される配列値のみ、危険があります。ただし、拡張モジュールでは拡張されたデータムを他に使っているかもしれません。

    本障害で「ERROR: cache lookup failed for type 0」(数値 0 の部分は様々)、または、クラッシュが生じる可能性があります。

  17. postgres -C で指定した設定変数が NULL文字列値を持つときのクラッシュが回避されました。 (Michael Paquier) (9.5)(9.4)(9.3)(9.2)

    18. OS X でクラッシュが報告されていました。

  18. wal senderプロセスにおいて、意図せず WAL receiver 応答を待機する動作が防止されました。 (Kyotaro Horiguchi) (9.5)
  19. ロジカルデコーディングで巨大なサブトランザクションが一部あるいは全部欠ける可能性があり、修正されました。 (Petru-Florin Mihancea) (9.5)(9.4)
  20. ロジカルデコーディングで、サブトランザクションに実質的な変更を含まず、外側のトランザクションが変更を含んでいる場合に、デコードに失敗するのが修正されました。 (Marko Tiikkaja, Andrew Gierth) (9.5)(9.4)

    21. 以下のようなトランザクションで、外側トランザクションでの INSERT がデコードされませんでした。 

    db=# BEGIN;
db=# INSERT INTO xact_test VALUES ('main-txn');
db=# SAVEPOINT foo;
db=# SELECT 1 FROM xact_test FOR UPDATE ;
db=# COMMIT;
  21. バックエンドが共有カタログの最新の統計を確実に見るようになりました。 (Tom Lane) (9.5)(9.4)(9.3)

    22. 統計情報コレクタは、通常バックエンドからの要求後、共有カタログについて統計ファイルの更新に失敗していました。この問題は、自動VACUUMランチャーが定期的に更新を生じさせる要求を出すため、部分的に隠されていました。しかし、自動VACUUM を無効にして露見しました。

    共有カタログにはデータベース単位でなく、インスタンス単位の情報が記録されます。

  22. 複数バックエンドが近接して共に更新を要求したとき、統計ファイルの冗長な書き込みを回避するようになりました。 (Tom Lane, Tomas Vondra) (9.5)(9.4)(9.3)
  23. VACUUM でトランザクションID の消費を回避するようになりました。 (Alexander Korotkov) (9.5)(9.4)(9.3)(9.2)(9.1)

    24. 一部ケースで VACUUM は不要に XID を現在トランザクションに割り当てました。通常これはごく僅かですが、XID周回の上限に直面したとき、XID周回対策の VACUUM でさらに多くの XID を消費するのは甚だ良くない動作です。

  24. 9.3 より前のバージョンから pg_upgrade でアップグレードしたインスタンスで、マルチトランザクションID の VACUUM処理にて失敗する可能性があり、修正されました。 (Andrew Gierth, Álvaro Herrera) (9.5)(9.4)(9.3)

    25. 本障害のよくある症状は以下のようなエラーです。 

    ERROR:  MultiXactId NNN has not been created yet -- apparent wraparound.
  25. カラムリストを指定した手動 ANALYZE ではテーブルの changes_since_analyze カウンタをリセットしなくなりました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)

    26. ANALYZEコマンドは以下のように特定テーブルの特定カラムを指定して実行することができます。 

    =# ANALYZE t25 (col1, col2);

    このような一部のカラムのみの ANALYZE を行なっている場合に、他のカラムのための自動ANALYZE が阻害されるべきではありません。

  26. ANALYZE で多数のヌルエントリがある、ユニークかほぼユニークなカラムに対する n_distinct の過大評価が修正されました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)

    27. 各 null が、それぞれ別の値である(distinct)とカウントされており、いくつかのクエリ形式では、深刻なプランナの予測間違いに繋がります。

  27. autovacuum で、同じ共有カタログに対して複数のワーカが処理開始するのを避けるようになりました。 (Álvaro Herrera) (9.5)(9.4)(9.3)(9.2)(9.1)

    28. 通常、vacuum は長くかからないので、これは大きな問題になりません。しかし稀に深刻に肥大化したカタログのケースでは、ひとつを除きすべてのワーカが、他のテーブルで有益な作業をせずに、無駄に待機する結果になります。

  28. B-Tree のマーク/リストア処理のバグが修正されました。 (Kevin Grittner) (9.5)

    29. この間違いは、マージジョインの内側ノードが B-Treeインデックススキャンの時に、誤った結合結果やアサーション失敗をひき起こす原因となっていました。

  29. B-Tree インデックスページの削除が中断された時、二重にバッファロック解放が行われるのを回避するようになりました。 (Tom Lane) (9.5)(9.4)

    30. この間違いは、壊れたB-Treeインデックスを伴ういくつかのケースで VACUUM完了を妨げます。VACUUM で以下のエラーが出るケースが報告されています。 

    ERROR:  lock main NNNNN is not held
  30. 巨大な(shared_buffers を越える)ハッシュインデックスの作成が修正されました。 (Tom Lane) (9.5)

    31. 巨大なインデックスの際に使われるコードパスに不具合があり、誤ったハッシュ値がインデックスに挿入されます。そのため、初期構築後にインデックスに挿入されたタプルを除き、その後のインデックスサーチは常に失敗しました。

    エラーが出るのではなく、本来見つかるべき行が見つからない結果になります。

  31. GiSTインデックス作成で幾何データ型カラムの成分に NaN値を含む場合に無限ループになる可能性が防止されました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)

    32. box型に対する CREATE INDEX ... USING gist ... コマンドが応答しない動作が、報告されています。

  32. contrib/btree_gistインデックスの intervalカラムを使った、近傍検索(ORDER BY distance) インデックススキャンで、クラッシュする可能性があり、修正されました。 (Peter Geoghegan) (9.5)
  33. BRINインデックスエントリを更新する時、BRINタプルの追加に失敗するケースの PANIC が修正されました。 (Álvaro Herrera) (9.5)

    34. 以下のように PANIC が生じて、マスタプロセスの停止または再起動が生じていました。 

    WARNING:  specified item offset is too large
PANIC:  failed to add BRIN tuple
  34. バックグラウンドワーカの停止時に、バックグラウンドワーカを制御するバックエンドプロセスがクラッシュする可能性あり、修正されました。 (Dmitry Ivanov) (9.5)
  35. PL/pgSQL で IMPORT FOREIGN SCHEMA コマンド内の INTO 句の扱いが修正されました。 (Tom Lane) (9.5)

    36. これまで PL/pgSQL内では、INTO 付きの IMPORT FOREIGN SCHEMA が動作しませんでした。

  36. contrib/btree_gin が bigint型の最小値を正しく扱えるように修正されました。 (Peter Eisentraut) (9.5)(9.4)(9.3)(9.2)(9.1)
  37. libpq が将来のサーババージョンを正しく解釈できるようになりました。 (Peter Eisentraut) (9.5)(9.4)(9.3)(9.2)(9.1)

    38. 9.6 以降のリリースでは、サーババージョンが現在の 3 パートから、2パートに変更される計画です。PQserverVersion() がその様な時にも正しい値を返すようになりました。

  38. "unsigned long long" 型の配列要素に関する ecpg コードが修正されました。 (Michael Meskes) (9.5)(9.4)(9.3)(9.2)(9.1)
  39. pg_dump の -c と -C オプションで、不要な CREATE SCHEMA public コマンドが出力されないようになりました。 (David Johnston, Tom Lane) (9.5)(9.4)(9.3)(9.2)
  40. パラレル pg_dump と pg_restore で SIGTERM や Ctrl-C の扱いが改善されました。 (Tom Lane) (9.5)(9.4)(9.3)

    41. ワーカプロセスが速やかに終了するようになり、また、CREATE INDEX の様な長時間実行されるケースに対応するため、クエリキャンセル要求が接続されたバックエンドに送られるようになりました。

  41. パラレル pg_dump と pg_restore のエラー報告が修正されました。 (Tom Lane) (9.5)(9.4)(9.3)

    42. これまでは、pg_dump や pg_restore のワーカプロセスからのエラーメッセージがユーザのコンソールに出力されないことがありました。

    メッセージはマスタプロセスを通して伝達されますが、いくつかデッドロックするシナリオがあり、マスタプロセスのメッセージ伝搬を妨げていました。代わりとして単純に stderr にすべてを出力します。いくつかのケースでは、重複するメッセージが出力されることになります。例えばすべてのワーカがサーバシャットダウンを報告します。

  42. Windows でのパラレル pg_dump や pg_restore で、エラー後は適切に停止するようになりました。 (Kyotaro Horiguchi) (9.5)(9.4)(9.3)

    43. 以前までは、エラーは報告するけれど、ユーザが手動で停止するまで居座っていました。

  43. スタンバイサーバに対するパラレル pg_dump が適切に失敗するようになりました。 (Magnus Hagander) (9.5)

    44. --no-synchronized-snapshots が指定されていない場合、この使い方はサポートされませんが、エラーが適切に処理されていませんでした。

  44. zlib サポートなしでビルドされた pg_dump の振る舞いが改善されました。 (Kyotaro Horiguchi) (9.5)(9.4)(9.3)

    45. パラレルダンプが正しく動作しなかったり、無意味な警告が発せられるケースがありました。圧縮を必要としないオプションであるにも拘らず、以下メッセージが出る場合が報告されています。 

    pg_dump: [archiver] WARNING: requested compression not available in this installation -- archive will be uncompressed
pg_dump: [parallel archiver] not built with zlib support
  45. pg_basebackup は -Z 0 で圧縮なし指定と受け取るようになりました。 (Fujii Masao) (9.5)(9.4)(9.3)(9.2)(9.1)

    46. これまでは無効な圧縮レベルであるとして、「pg_basebackup: invalid compression level ...」というエラーになっていました。

  46. パラレルメイクで AIX の共有ライブラリを安全にビルドできるようにmakefile のルールを修正しました。 (Noah Misch) (9.5)(9.4)(9.3)(9.2)(9.1)
  47. TAP テストと MSVC スクリプトが、ビルドディレクトリパス名に空白が含まれていても、動くようになりました。 (Michael Paquier, Kyotaro Horiguchi) (9.5)(9.4)(9.3)(9.2)(9.1)
  48. statement_timeout と lock_timeout の報告が、より予測可能になりました。 (Tom Lane) (9.5)(9.4)(9.3)

    49. 負荷の高いマシンでは、ステートメントタイムアウトが先に発生したのに、ロックタイムアウトが報告されるため、リグレッションテストが時々失敗していました。

  49. デンマーク語とウェールズ語ロケールでのレグレッションテストが安全になりました。 (Jeff Janes, Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)

    50. これらのロケールで通常と異なるソートルールの引金になるテストデータが修正されました。

  50. タイムゾーンコードのコピーが IANA の tzcode release 2016c に合わせて更新されました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)

    51. これはタイムゾーンデータファイルの将来の変更を見越した対応で必要になります。また通常と異なるタイムゾーンの対処で、稀にあるバグを修正しています。

  51. タイムゾーンデータが tzdata release 2016f に更新されました。 (9.5)(9.4)(9.3)(9.2)(9.1)

    52. ケメロヴォとノヴォシビルスクの夏時間の変更と、アゼルバイジャン、ベラルーシ、およびモロッコの歴史的な修正が含まれます。

  52. hot standby クエリが VACUUM FREEZE でキャンセルされないようになりました。 (Simon Riggs, Álvaro Herrera) (9.4)(9.3)(9.2)(9.1)

    53. アイドルではないマスタサーバ上の VACUUM FREEZE は、スタンバイサーバのクエリを不必要にキャンセルすることがありました。

  53. pg_ctl start -w のタイムアウトが古いヒューリスティックな方法に戻りました。 (Tom Lane) (9.1)

    54. 9.1.20 から採用された新しい方法は silent_mode が有効な時にうまく動きません。そのため古い方法に戻されました。

関連記事:

  1. PostgreSQL 9.1.20 に関する技術情報
  2. PostgreSQL 9.1.21 に関する技術情報
  3. PostgreSQL 9.1.22 に関する技術情報
  4. PostgreSQL 9.1.24 に関する技術情報