このリリースは 9.0.15 からの修正リリース(2014/2/20リリース)です。
9.0.x からのアップデートではダンプ、リストアは不要です。
また、9.0.15 より前のバージョンからアップデートを行う場合は 9.0.15 に関する技術情報を参照してください。
PostgreSQL 9.0.15 から 9.0.16 への変更点
9.3.3、9.2.7、9.1.12、9.0.16、8.4.20 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。
- ロールに対する GRANT ... WITH ADMIN OPTION の制限が強化されました (Noah Misch) (9.3)(9.2)(9.1)(9.0)(8.4)
- 手続き言語の有効性検証関数の手動呼び出しによる特権昇格を防止するようになりました (Andres Freund) (9.3)(9.2)(9.1)(9.0)(8.4)
- 並行した DDL によるテーブルやインデックスの照合を避けるようになりました (Robert Haas, Andres Freund) (9.3)(9.2)(9.1)(9.0)(8.4)
- 長い日付時刻文字列に対するバッファーオーバーランを防ぐようになりました (Noah Misch) (9.3)(9.2)(9.1)(9.0)(8.4)
- 整数オーバーフローによるバッファーオーバランを防ぐようになりました (Noah Misch, Heikki Linnakangas) (9.3)(9.2)(9.1)(9.0)(8.4)
- 潜在的なバッファオーバーラン危険性が修正されました (Peter Eisentraut, Jozef Mlich) (9.3)(9.2)(9.1)(9.0)(8.4)
- chkpass追加モジュールが crypt() から NULL が返ることでクラッシュするのを防ぐようになりました (Honza Horak, Bruce Momjian) (9.3)(9.2)(9.1)(9.0)(8.4)
- ドキュメントに再帰テスト(regression test) 実行時の注意事項が追記されました (Noah Misch, Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)
- タプル凍結のロジックが修正されました (Álvaro Herrera, Andres Freund) (9.3)
- MultiXactId 凍結に関する設定パラメータが追加されました (Álvaro Herrera) (9.3)
- UPDATE により共有行ロックの伝搬が無視されてしまう障害が修正されました (Álvaro Herrera) (9.3)
- 同時実行トランザクションで行ロックが無視されてしまう可能性があり、修正されました。 (Álvaro Herrera) (9.3)
- 更新連鎖ロックの誤ったロジックが修正されました。 (Álvaro Herrera) (9.3)
- pg_multixact/members が正しく周回処理されるように修正されました。 (Andres Freund, Álvaro Herrera) (9.3)
- pg_multixact/members の 5桁ファイル名の扱いが修正されました (Álvaro Herrera) (9.3)
- マルチトランザクションID のキャッシュ処理の性能が改善されました (Álvaro Herrera) (9.3)
- 同一トランザクション内でロックされている行の更新が最適化されました (Andres Freund, Álvaro Herrera) (9.3)
- リカバリ時の pg_xlog と WALアーカイブのファイル選択順序が変更されました (Kyotaro Horiguchi) (9.3)
- リカバリで誤った更新の適用が生じる可能性があり、修正されました (Greg Stark, Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)
- リカバリが一貫性のあるところまで到達したかの判定が修正されました (Tomonari Katsumata, Heikki Linnakangas) (9.3)(9.2)(9.1)(9.0)
- VACUUM処理における可視性マップのビットセットの WAL出力が修正されました (Heikki Linnakangas) (9.3)
- ホットスタンバイの VACUUM 操作の WAL リプレイで、Btreeインデックスの不適切なロック処理が修正されました (Andres Freund, Heikki Linnakangas, Tom Lane) (9.3)(9.2)(9.1)(9.0)
- 非リーフの GIN インデックスページ挿入において、適宜にページ全体の WAL 記録をするようになりました (Heikki Linnakangas) (9.3)(9.2)(9.1)(9.0)(8.4)
- recovery.conf での pause_at_recovery_target と recovery_target_inclusiveを on に指定したとき、目標点の後で停止するようになりました (Heikki Linnakangas) (9.3)(9.2)(9.1)
- ホットスタンバイのフィードバック送信が確実に行われるようになりました (Andres Freund, Amit Kapila) (9.3)
- タイムアウト制御について修正されました (Andres Freund, Tom Lane) (9.3)
- プロセス終了時における処理の競合が修正されました (Robert Haas) (9.3)(9.2)(9.1)(9.0)(8.4)
- walsender、walreceiver のプロセス終了時に SIGHUP シグナルを受けた際の処理の競合が修正されました (Tom Lane) (9.3)(9.2)(9.1)
- エラーメッセージ出力部分で安全でないエラー番号の参照が修正されました (Christian Kruse) (9.3)(9.2)(9.1)(9.0)(8.4)
- PostgreSQL実装内におけるエラーレポート関数の利用について修正されました (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)
- SSL接続を受けたバックエンドプロセスが、クライアント側の突然の切断後にハングアップする問題が修正されました。 (Alexander Kukushkin) (9.3)(9.2)(9.1)(9.0)(8.4)
- Unicodeエスケープ形式で書かれた識別子の長さチェックメッセージがエスケープ解釈前の文字列長で行われており、修正されました。 (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)
- コマンド末尾または関数本体末尾における Unicodeリテラルと Unicode識別子の構文解析が修正されました (Tom Lane) (9.3)
- 型名キーワードがロール名リストで使えるようになりました。 (Stephen Frost) (9.3)(9.2)(9.1)(9.0)
- カラムの無いテーブルに対する EXISTS サブクエリを含む SQL の構文解析でクラッシュする障害が修正されました (Tom Lane) (9.3)(9.2)(9.1)
- 「WHERE (... x IN (SELECT ...) ...) IN (SELECT ...)」という形の条件式を持つ SQL に誤ったプランが作られ、クラッシュする障害が修正されました (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)
- LATERAL 構文を使った外部結合についてプランナが修正されました。 (Tom Lane) (9.3)
- UPDATE/DELETE における対象テーブルへの LATERAL参照が修正されました。 (Tom Lane) (9.3)
- サブクエリに UNION ALL を含む、継承テーブルへの UPDATE、DELETE について修正されました。 (Tom Lane) (9.3)(9.2)
- 範囲データ型のドメインのカラムに対する ANALYZE が失敗する障害が修正されました (Tom Lane) (9.3)
- ANALYZE で全ての値が大きいサイズのカラムに対応しました。 (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)
- デフォルトテーブルスペースに対して CREATE TABLE を実行する際に、テーブルスペースにおける CREATE権限のチェックは行わなくなりました (Stephen Frost) (9.3)(9.2)(9.1)(9.0)(8.4)
- イベントトリガーの拡張モジュール対応誤りが修正されました (Tom Lane) (9.3)
- CASE が複数行を返す関数を戻り式としているときエラーがでる問題が修正されました (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)
- JSON関数で処理後に一時的に確保したメモリを解放するようになりました (Craig Ringer) (9.3)
- JSON型データ生成で不正な数値を適切に判別できるように修正されました (Andrew Dunstan) (9.3)(9.2)
- pg_stat_activity ビューで使われる関数でクライアントアドレスがゼロかチェックする箇所が修正されました。 (Kevin Grittner) (9.3)(9.2)(9.1)(9.0)(8.4)
- テキスト全文検索（tsearch）にて、一部のマルチバイト文字について障害が修正されました (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)
- テキスト全文検索の実装にて memcopy() の替わりに memmove() を使うように修正されました (Heikki Linnakangas) (9.3)(9.2)(9.1)(9.0)(8.4)
- pg_basebackup コマンドに対応したサーバ側実装において、権限チェックを行う位置が変更されました。 (Andres Freund, Magnus Hagander) (9.3)(9.2)(9.1)
- ロケールチェック用で文字エンコーディング名 SHIFT_JIS に対応しました (Tatsuo Ishii) (9.3)(9.2)(9.1)(9.0)(8.4)
- SQL関数の複合型引数に対する「*」を使った指定における障害が修正されました (Tom Lane) (9.3)(9.2)
- libpq が Windows で host も hostaddr も指定しない場合、localhost が接続先となるように修正されました (Fujii Masao) (9.3)(9.2)(9.1)(9.0)(8.4)
- psql で COPY TO STDOUT、COPY FROM STDIN におけるエラー時の処理がいくつか修正されました (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)
- psql の ?df+、?dc+、?dC+ における翻訳可能カラム指定が修正されました (Peter Eisentraut, Tom Lane) (9.3)(9.2)
- pg_basebackup のフォアグラウンドプロセスがエラー終了する時にバックグラウンドプロセスを停止するように修正されました (Magnus Hagander) (9.3)(9.2)
- pg_basebackup で -v (--verbose) を指定し、tarフォーマットを標準出力に書き出す場合に、未初期化データが出力される障害が修正されました (Magnus Hagander) (9.3)(9.2)(9.1)
- データベースクラスタディレクトリ（$PGDATA）内にテーブルスペースがある場合に、ベースバックアップ内に２重に含まないように修正されました (Dimitri Fontaine, Magnus Hagander) (9.3)(9.2)(9.1)
- ecpg で記述子の出力について修正されました (MauMau) (9.3)(9.2)(9.1)(9.0)(8.4)
- ecpg で接続時にホスト名が与えられていないとき、空のホスト名で接続を試みないように修正されました (Michael Meskes) (9.3)(9.2)(9.1)(9.0)(8.4)
- dblink の接続処理オーバーヘッドが軽減されました (Joe Conway) (9.3)(9.2)(9.1)(9.0)(8.4)
- 追加モジュール isn で ISMNチェックディジットの計算が修正されました (Fabien Coelho) (9.3)(9.2)(9.1)(9.0)(8.4)
- pgbench で 巨大なスケールファクターを指定したときの整数オーバーフローが修正されました (Tatsuo Ishii) (9.3)
- pg_stat_statement 追加モジュールで、CURRENT_DATE、CURRENT_TIME 等のパース処理部分の実装が微調整されました (Kyotaro Horiguchi) (9.3)(9.2)
- postgres_fdw 追加モジュールで、接続が切れた場合のエラー処理が改善されました (Tom Lane) (9.3)
- クライアントのみインストールする場合について Makefile が修正されました (Peter Eisentraut) (9.3)(9.2)(9.1)(9.0)(8.4)
- Mingw と Cygwin プラットフォームにおいてインストール(make install)時にlibpq.dll を bin ディレクトリに配置するようになりました (Andrew Dunstan) (9.3)(9.2)(9.1)(9.0)(8.4)
- 使用が推奨されない dllwrap を Cygwin にて使用しないようになりました (Marco Atzeri) (9.3)(9.2)(9.1)(9.0)
- Visual Studio 2013 でビルドできるようになりました (Brar Piening) (9.3)
- これまでプレーンテキストでリリース情報が記載されていた HISTORY ファイルが廃止されました (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)
- タイムゾーンデータが tzdata release 2013i に更新されました (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)
ADMIN OPTION 無しでロールに権限を与えることで、そのロールにはメンバー追加削除できないことが期待されます。しかし、SET ROLE コマンドを先に行うという抜け道がありました。
本障害は CVE-2014-0060 として登録されています。
(例)
$ psql -U u1 db1
db1=> ?du
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------+-----------
g1 | Cannot login | {}
postgres | Superuser, Create role, Create DB, Replication | {}
u1 | | {g1}
u2 | | {}
db1=> GRANT g1 TO u2;
ERROR: must have admin option on role "g1"
db1=> SET ROLE g1;
SET
db1=> GRANT g1 TO u2;
GRANT ROLE
db1=> REVOKE g1 FROM u2;
REVOKE ROLE
手続き言語の有効性検証関数（PL validator）は、暗黙的に CREATE FUNCTION実行時に呼ばれますが、明示的に関数呼び出しすることもできます。これを利用した特権昇格(privilege escalation) が可能
でした。
本修正では、付属する手続き言語について、有効性検証関数に権限チェック処理を加えました。外部配布の手続き言語についても、同様の問題があるかもしれません。
本障害は CVE-2014-0061 として登録されています。
DDLコマンドを並行して複数実行しているときの DDLコマンド実行過程で、テーブル・インデックスを名前から実体を特定したとき、実行部分によって異なるものが選ばれてしまうことがありました。これを使い、少なくとも CREATE INDEX で、インデックス作成対象と異なるテーブルに権限チェックが行われ、特権昇格が可能でした。
本障害は CVE-2014-0062 として登録されています。
interval型の出力と timestamp型の入力において、処理用の固定バッファサイズが可能な最大サイズと比べて小さく、バッファオーバーランをひき起こす可能性がありました。また、ecpgライブラリにも同様の問題がありました。
本障害は CVE-2014-0063 として登録されています。
いくつかの組み込み関数（大部分はデータ型入力関数）でメモリサイズ計算値がオーバーフローのチェックなしに使われていました。整数オーバーフローが生じると過小なメモリ確保サイズとなり、バッファオーバーランをひき起こします。
hstore、intarray、ltree の各追加モジュールと、path型、ビット列データ型、全文検索(tsquery)、txid_current_snapshot()、txid_snapshot_recv() 関数、にて修正されています。
本障害は CVE-2014-0064 として登録されています。
実装において strcpy() や strncpy() が strlcpy() に置き換えられました。実際に問題が発現するかは不明で、Coverityツールによるチェック結果に対応した修正となります。
本障害は CVE-2014-0065 として登録されています。
起こりうるケースとしては、libc が許可されていないハッシュアルゴリズムを拒否するように構成されている場合 (FIPS モードなど) があります。
本障害は CVE-2014-0066 として登録されています。
make check により一時的な PostgreSQL サーバプロセスを起動する間、そこには同マシンからパスワード認証なしでアクセス可能となり、テストを実行した OS上のユーザの権限を不正利用される潜在的な危険性がありました。
ドキュメントに同マシンに信頼できないユーザがいる際にリスクがあるという警告が記載されました。
本問題は CVE-2014-0067 として登録されています。
これまで共有行ロックの制御に使われる MultiXactId の凍結を伴う場合に正しく処理できていませんでした。古い共有行レベルロックが忘れられてしまう可能性があります。
修正にあたって WALレコードの書式が変更されました。レプリケーションをしている場合、スタンバイサーバを先にバージョンアップする必要があります。プライマリを先にバージョンアップして、プライマリから凍結処理をする WALレコードを受け取ったスタンバイ側サーバは、PANIC メッセージを出して止まってしまいます。
マルチトランザクションID (MultiXactId、mutixact) は、共有行ロックを実現するものです。各タプル(行バージョン) の 削除時トランザクションID(XID) と同じ場所に格納され、infomaskフラグにより
MultiXactId であることが識別されます。
通常のタプルの XID と同様に 古くなりすぎる前にタプルの MultiXactId を凍結しなければいけません。これまでは autovacuum_freeze_max_age やvacuum_freeze_min_age、vacuum_freeze_table_age な
どの XID 凍結用のパラメータを MultiXactId にも適用していました。
しかし、XID と MultiXactId で進行スピードが大きく異なるとき、うまく動作しません。そのため、専用のパラメータが新設されました。
(追加された設定パラメータ) vacuum_multixact_freeze_min_age vacuum_multixact_freeze_table_age autovacuum_multixact_freeze_max_age
行がトランザクションＡにロックされていて、その行がトランザクションＢによって UPDATE されたなら、その時点でトランザクションＢからしか見えない行データであるとしても、更新後の行は引き続きトランザクションＡによってロックされているべきです。
本障害で、トランザクションＢにおけるその後の DELETE や UPDATE にて、ロックのチェックが抜けていました。これにより読み取り整合性が崩れてしまいます。
以下に再現シナリオを示します。
トランザクションＡ トランザクションＢ
BEGIN; BEGIN;
SELECT * FROM t1
WHERE id = 1 FOR KEY SHARE;
DELETE FROM t1 WHERE id = 1;
(⇒ ブロックする／正しい動作）
ROLLBACK;
ROLLBACK;
BEGIN; BEGIN
SELECT * FROM t1
WHERE id = 1 FOR KEY SHARE;
UPDATE t1 SET v = 10001 WHERE id = 1;
(⇒ キー以外の更新はブロックしない／正しい動作)
DELETE FROM t1 WHERE id = 1;
(⇒ ブロックしない／誤った動作)
COMMIT;
SELECT * FROM t1 WHERE id = 1;
(⇒ (0 rows) となる／想定外の結果)
COMMIT;
上記項目とは別の原因で共有行ロックが無視されてしまいます。外部キー制約によりブロックされているべき状況で UPDATE できてしまう可能性がありました。
REPEATABLE READ または SERIALIZABLE 隔離レベルのトランザクションにて、本来出るべきでない直列化失敗エラー「ERROR: could not serialize access due to concurrent update」をひき起こします。
pg_multixact/members ディレクトリ内のファイル群は、共有行ロック(select ... for share) を制御するものです。2^32 (約42億) の要素を扱うことができ、これを超えたときの周回処理に不具合がありました。
以下のようなエラーが出ることが報告されています。
error: could not access status of transaction 24568845 detail: could not open file "pg_multixact/members/f615": no such file or directory.
PostgreSQL 9.3 から pg_multixact/members 以下に 5桁以上のファイル名がありえましたが、ディレクトリ内をクリーンアップする処理でそれらを無視するようになっていました。
SELECT FOR UPDATE に続く、UPDATE と DELETE が性能改善されます。DBT2試験で PostgreSQL 9.2.x と比べて 15％程度の性能ダウンが報告されていました。
アーカイブリカバリにおいて、pg_xlog と WALアーカイブに同ID でタイムラインが異なる WALセグメントファイルがあった場合、これまで WALアーカイブにある方が優先されていましたが、タイムライン
が新しい方を選択するようになりました。
これまでの振る舞いでは、未だアーカイブされていない WALセグメントファイルをリカバリに適用できないことがありました。
WAL更新が誤って本来の位置よりも先にあるページに適用されることがありえました。
リカバリ中のサーバ（スタンバイサーバ）において、ファイルの肥大化やデータ破壊を引き起こします。肥大化はファイル末尾よりも先の位置のページに書き込みが生じるために起こります。
本障害により、hot_standby モードのリカバリ中サーバ（スタンバイサーバ）が参照アクセスの接続を受け付けるのが早すぎて、「PANIC: WAL contains references to invalid pages」によるサービスダ
ウンが生じる可能性がありました。
該当する VACUUM処理について出力した WAL でリカバリしたときに、あるページに削除済み行が残っているのに可視性マップ（ビジビリティマップ）では、全て可視であるとされるケースが生じていました。
WALリプレイ過程で、全てゼロの使われないインデックスページのスキャンで「PANIC: WAL contains references to invalid pages」が生じて止まってしまう可能性がありました。
インデックス への VACUUM のリプレイで追加ロックを取る条件が正しくなく、誤ったページが読み取りされるおそれがありました。
インデックスの最後のページが全てゼロである場合に正しく処理されませんでした。
システムクラッシュ時にインデックスが破損する危険がありました。
これまで pause_at_recovery_target = true の場合、たとえrecovery_target_inclusive = true であってもリカバリは目標点の手前で停止していました。その後、pg_xlog_replay_resume() を実行すると、目標点の WALレコードをリカバリしてからリカバリを終了しますので、リカバリ停止して確認した時点より、１歩進んだ状態となってしまいます。
これまで walsenderプロセスが忙しいとき、ホットスタンバイからのフィードバックが送られない動作となっていました。
PostgreSQL 9.3.2 の修正で導入されてしまった障害です。statement_timeout を使っているアプリケーションでは、タイムアウト発生時に奇妙なエラーが生じる可能性があります。
本障害により「PANIC: stuck spinlock」等の PANIC が生じてサーバ全体がダウンしたり、停止できないバックエンドプロセスが生じるケース等が報告されています。
プロセス終了時の特定タイミングで SIGUSR1 等のシグナルを受け取った際にバックエンドプロセスのクラッシュをひき起こす可能性がありました。
Clangベースのコンパイラでビルドした場合で HINT メッセージに適切な内容が出力されないという障害が報告されていました。
メモリコンテキストの初期化が済んでいない段階でエラーレポート関数が使われて、エラーメッセージが出るべきところでクラッシュするケースがありました。
あくまで奇妙なメッセージが出るだけの問題です。
(例：識別子最長は 63バイト)
db=# SELECT octet_length(U&'?0441?043B?043E?043D?0441?043B?043E?043D?0441?043B?043E?043D?0441?043B?043E?043D');
octet_length
--------------
32
db=# CREATE TABLE t1 (U&"?0441?043B?043E?043D?0441?043B?043E?043D?0441?043B?043E?043D?0441?043B?043E?043D" text);
NOTICE: identifier "слонслонслонслон" will be truncated to "слонслонслонслон"
CREATE TABLE
db=# CREATE TABLE t2 ("слонслонслонслон" text);
CREATE TABLE
型名キーワード(type_func_name_keyword) とは、型名または関数名でクオート無しに利用可能なキーワードです。BINARY、COLLATION、LIKE、IS などが含まれます。9.3.1 (その他 2013/10/10 リリースマイナーバージョン) でキーワードの利用制限が緩められましたが、ロール名リストで利用できませんでした。
(従来の使えない場合の例) db=# CREATE ROLE like; CREATE ROLE db=# CREATE ROLE is; CREATE ROLE db=# DROP ROLE like, is; ERROR: syntax error at or near "like" LINE 1: DROP ROLE like, is;
(例) db=# CREATE TABLE zero_column_table (); db=# SELECT 1 WHERE EXISTS (SELECT * FROM zero_column_table); The connection to the server was lost. Attempting reset: Failed. LOG: server process (PID 1234) was terminated by signal 11: Segmentation fault DETAIL: Failed process was running: SELECT 1 WHERE EXISTS (SELECT * FROM zero_column_table);
(クラッシュする SQL例)
db=# CREATE TABLE ta AS SELECT 1 AS a1, 1 AS a2;
db=# CREATE TABLE tb AS SELECT 1 AS b1, 1 AS b2;
db=# SELECT * FROM ta
WHERE (CASE WHEN a1 IN (SELECT b1 FROM tb) THEN a1 ELSE NULL END)
IN (SELECT b2 FROM tb);
The connection to the server was lost. Attempting reset: Failed.
LOG: server process (PID 1234) was terminated by signal 11: Segmentation fault
以下の SQL で「ERROR: JOIN qualification cannot refer to other relations」が出る障害が報告されました。
SELECT * FROM (SELECT 1 AS x) x CROSS JOIN (SELECT 1 AS y) y LEFT JOIN LATERAL ( SELECT * FROM (SELECT 1 AS z) z WHERE z.z = x.x) z ON z.z = y.y;
PostgreSQL 9.3 から LATERAL構文に対応して、同じサブクエリ階層にある別テーブルを参照できるようになりました。このとき UPDATE、DELETE については以下のように「LATERAL」と書かなくとも、同階層のテーブルを参照できてしまっていました。
UPDATE ta SET a2 = ss.b2 FROM (SELECT * FROM tb where b1 = ta.a1) ss; DELETE FROM ta USING (SELECT * FROM tb where b1 = ta.a1) ss;
本修正で上記はエラーとなります。本来は以下のように「LATERAL」を記述しなければいけません。
UPDATE ta SET a2 = ss.b2 FROM LATERAL (SELECT * FROM tb where b1 = ta.a1) ss; DELETE FROM ta USING LATERAL (SELECT * FROM tb where b1 = ta.a1) ss;
該当する形状の SQL で誤った動作が発生していました。典型的には子テーブルに対して、UPDATE、DELETE が適用されないという挙動になります。
(再現例)
CREATE TABLE t_inh_p (k int, c int);
CREATE TABLE t_inh_sub () INHERITS (t_inh_p);
CREATE TABLE t_other (k int);
INSERT INTO t_inh_p VALUES (1,1),(2,2);
INSERT INTO t_inh_sub VALUES (1,1),(2,2);
INSERT INTO t_other VALUES (1),(2);
UPDATE t_inh_p SET c = c + 100
FROM ( SELECT k FROM t_other UNION ALL SELECT k + 1 FROM t_other ) ss
WHERE t_inh_p.k = ss.k;
SELECT tableoid::regclass::text, * FROM t_inh_p;
(以下のように子テーブルの c が +100 されません)
tableoid | k | c
-----------+---+-----
t_inh_p | 1 | 101
t_inh_p | 2 | 102
t_inh_sub | 1 | 1
t_inh_sub | 2 | 2
以下にエラー発生例を示します。
db=# CREATE DOMAIN d_rts AS tstzrange; db=# CREATE TABLE t_dm (c d_rts); db=# ANALYZE t_dm; ERROR: type 26739 is not a range type
ANALYZE でカラム統計情報を収集する際に、メモリ使用量を抑えるため定数値 WIDTH_THRESHOLD (1024 バイト) を超える値をスキップするようにはなっていましたが、全ての値が閾値を超えていると当該
カラムついて正しく統計情報を取得できない結果となっていました。
これまで CREATE TABLE では権限チェックがされていない一方で、ALTER TABLE ... SET TABLESPACE で権限チェックが行われていました。
CREATE EXTENSION コマンド経由で CREATE EVENT TRIGGER コマンドを実行しても拡張モジュールへの所属が登録されませんでした。また、拡張モジュール所属のイベントトリガが pg_dump でダンプ対象から除外されませんでした。
エラー「ERROR: set-valued function called in context that cannot accept a set」が生じます。
以下はエラーをひき起こす SQL 例です。regexp_matches は、本SQL で与えられる引数では 1行しか返しませんが、定義としては複数行を返す関数です。
SELECT *, lower(CASE
WHEN id = 2 THEN (regexp_matches(str, '^0*([1-9]?d+)$'))[1]
ELSE str END)
FROM (VALUES (1,''), (2,'0000000049404'), (3,'FROM 10000000876'))
v(id, str);
本障害は 8.0 から存在していましたが、8.4 以降バージョンのみ修正されます。
以下のように money型にキャストして $ 付きのまま JSONデータ内に格納できてしまうけれども、要素の取り出し時点でエラーとなるケースが報告されました。
db=# SELECT to_json(a) FROM (VALUES(1000::money)) a(salary);
to_json
-----------------------
{"salary":$1,000.00}
(1 row)
db=# SELECT to_json(a)->'salary' FROM (VALUES(1000::money)) a(salary);
ERROR: invalid input syntax for type json
クライアントアドレスの表示で誤った動作をする可能性がありますが、ほとんどの場合に発生しません。本障害は障害報告ではなくコード解析によって発見されました。
検索されるべきでない要素が結果に含まれてしまう可能性がありました。
具体的な障害報告は出ていませんが、誤った結果が返ったり、クラッシュをひき起こしたりする可能性がありました。
これまでシステムテーブルへの不要なアクセスが生じていました。
RHEL 6.x などで以下のように ja_JP.SJIS ロケールを設定した場合に該当します。クライアントコマンド実行時に警告が出力されていました。
# localdef -f SHIFT_JIS -i ja_JP /usr/lib/locale/ja_JP.SJIS # export LANG=ja_JP.SJIS # createdb -U postgres testdb could not determine encoding for locale "ja_JP.SJIS": codeset is "SHIFT_JIS"
$1.* は動作しますが、x.* は動作しませんでした。関数定義時にバックエンドプロセスのクラッシュが生じる障害が報告されました。
(例)
db=# CREATE TABLE foo ( x int ) ;
db=# CREATE FUNCTION zzz(v foo) RETURNS VOID AS $$
INSERT INTO foo(x) VALUES (v.*) $$ language SQL;
The connection to the server was lost. Attempting reset: Failed.
LOG: server process (PID 1234) was terminated by signal 11: Segmentation fault
localhost になることはドキュメントに記載されていましたが、実装がそのようになっていませんでした。
9.2 以上のサーバで COPY FROM STDIN 実行中に切断した場合に無限ループに陥る可能性がありました。また、プロトコルバージョン 2 のサーバに対して無限ループに陥る可能性がありました。
NLS を有効にしている場合に誤った翻訳出力がされる可能性がありました。9.3系では ?dy についても修正されました。
ここでのバックグラウンドプロセスとは、サーバ側の postgresプロセスではなくpg_basebackup の子プロセスです。
SPARC Solaris プラットフォームで SIGBUS (バスエラー) によるクラッシュが報告されていました。
クライアントエンコーディングが一致している場合には、クライアントエンコーディングを設定する処理を行わなくなります。
これまで常に誤った値となっていました。
本障害で初期化時の表示で以下のようなマイナス値が出力されることがありました。
239300000 of 3800000000 tuples (-48%) done (elapsed 226.86 s, remaining -696.10 s).
動作内容の変更はありません。
ソースコードからクライアントのみインストールするドキュメント記載の手順ではpsqlrc.sample を配置するところでエラーになっていました。
ヨルダンの夏時間法の変更、キューバの歴史的変更が含まれます。また、IANA でメンテナンスされず、実際にも使われていない地域名 Asia/Riyadh87、Asia/Riyadh88、Asia/Riyadh89 が削除されました。