このリリースは 9.2.19 からの修正リリースです。
9.2.x からのアップデートではダンプ、リストアは不要です。
ただし、下記の 1 番目を確認してください。追加でインデックス再作成が必要な場合があります。
また、9.2.11 より前のバージョンからアップデートを行う場合は 9.2.11 に関する技術情報を参照してください。
PostgreSQL 9.2.19 から 9.2.20 への変更点
9.6.2、9.5.6、9.4.11、9.3.16、9.2.20 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。
- CREATE INDEX CONCURRENTLY によるインデックス作成で破損したインデックスをもたらす可能性のある競合状態が修正されました。 (Pavan Deolasee, Tom Lane) (9.6)(9.5)(9.4)(9.3)(9.2)
- システムテーブルのスキャンに使われる特別なスナップショットが、早すぎるデータ除去処理により無効になることが無いように修正されました。 (Tom Lane) (9.6)(9.5)(9.4)
- BRIN インデックスの誤った WAL 出力が修正されました。 (Kuntal Ghosh) (9.6)(9.5)
- 無条件に UNLOGGED テーブルの初期フォーク生成の WAL 出力をするようになりました。 (Michael Paquier) (9.6)(9.5)(9.4)(9.3)(9.2)
- 統計情報収集器 (stats collector process) が、ホットスタンバイ動作中に落ちたときにも再起動されるようになりました。 (Takayuki Tsunakawa) (9.6)(9.5)(9.4)(9.3)(9.2)
- スタンバイサーバ開始時に有効であったときに hot_standby_feedback 設定による動作が確実に正しく動作するようになりました。 (Ants Aasma, Craig Ringer) (9.6)(9.5)(9.4)(9.3)
- ホットスタンバイが衝突している問い合わせを待機している間、割り込みのチェックをするようになりました。 (Simon Riggs) (9.6)(9.5)(9.4)(9.3)(9.2)
- 稀なケースで恒常的に autovacuum launcher プロセスが再生成される動作を回避するようになりました。 (Amit Khandekar) (9.6)(9.5)(9.4)(9.3)(9.2)
- synchronous_standby_name で同期スタンバイの数に 0 を許さないようになりました。 (Fujii Masao) (9.6)
- ユーザ毎の接続数上限にバックグラウンドワーカプロセスを数えないようになりました。 (David Rowley) (9.6)
- 拡張モジュールの要素オブジェクトが削除できる場合のチェックが修正されました。 (Tom Lane) (9.6)(9.5)(9.4)(9.3)(9.2)
- ALTER EXTENSION ... ADD/DROP コマンドにて正しく動作するように、拡張モジュールの要素オブジェクトの初期権限の探知が修正されました。 (Stephen Frost) (9.6)
- インデックス再作成を伴う ALTER TABLE コマンドで、インデックスのテーブルスペース割り当てを確実に維持するように修正されました。 (Tom Lane, Michael Paquier) (9.6)(9.5)(9.4)(9.3)(9.2)
- ALTER TABLE ... ALTER CONSTRAINT で外部キー制約が遅延可能かを変更するときのトリガ関数プロパティの誤った更新が修正されました。 (Tom Lane) (9.6)(9.5)(9.4)
- 被参照テーブルに対する保留トリガイベントがあるときに外部キー制約を削除しないように修正されました。 (Tom Lane) (9.6)(9.5)(9.4)(9.3)(9.2)
- 子テーブルが親テーブルと異なる列順である場合の ALTER TABLE ... SET DATA TYPE ... USING ... コマンドの動作が修正されました。 (Álvaro Herrera) (9.6)(9.5)
- WITH OIDS 指定のテーブルが、同じくWITH OIDS 指定の親テーブルと ALTER TABLE ... INHERIT コマンドで関連づけられた場合の、OID 列の処理が修正されました。 (Amit Langote) (9.6)(9.5)(9.4)(9.3)(9.2)
- CREATE TABLE ... LIKE ... WITH OIDS コマンドが、LIKE で参照されるテーブルに OID がある無しにかかわらず、確実にテーブルを WITH OIDS で作成するように修正されました。 (Tom Lane) (9.6)
- 先にビュー問い合わせを置き換えてから、新しいビューオプションを適用するように、CREATE OR REPLACE VIEW コマンドを修正しました。 (Dean Rasheed) (9.6)(9.5)(9.4)
- ALTER TEXT SEARCH CONFIGURATION のとき、正しい OID を報告するようになりました。 (Artur Zakirov) (9.6)(9.5)(9.4)(9.3)
- コミットタイムスタンプの仕組みが、特別 XID の FrozenTransactionId (=2) と BootstrapTransactionId (=1) について問われた時に失敗しないように修正されました。 (Craig Ringer) (9.6)(9.5)
- ビューの reloptions を通常テーブルの reloptions のように誤用していたのが修正されました。 (Tom Lane) (9.6)(9.5)
- ON CONFLICT 構文を列数が多いテーブルに使った際に発生する障害が修正されました。 (Tom Lane) (9.6)(9.5)
- 削除した列を伴うテーブルに対する INSERT または UPDATE で、削除された列への値が供給されたという偽性のエラーが生じることがあり、修正されました。 (Tom Lane) (9.6)
- UPDATE の SET 句の代入元の式で foo.* の複数カラム展開が防止されました。 (Tom Lane) (9.6)(9.5)(9.4)(9.3)
- 複数行 VALUES 値に対して精密に列データ型修飾が決定されるようになりました。 (Tom Lane) (9.6)(9.5)(9.4)(9.3)(9.2)
- 文字列末尾で完結していないユニコードのサロゲートペアについてエラーを投げるようになりました。 (Tom Lane) (9.6)(9.5)(9.4)(9.3)(9.2)
- 同じ列を対象にした複数の順序集約があって遷移状態が共有できる場合の、DISTINCT と順序集約の実行が修正されました。 (Heikki Linnakangas) (9.6)
- tsquery のフレーズ検索演算子の実装が修正されました。 (Tom Lane) (9.6)
- 空文字列に対して否定テキスト検索がマッチするようになりました。 (Tom Dunstan) (9.6)(9.5)(9.4)(9.3)(9.2)
- ts_rewrite() が非トップレベルのサブツリーを空クエリで置き換えた際のクラッシュが防止されました。 (Artur Zakirov) (9.6)(9.5)(9.4)(9.3)(9.2)
- ts_rewrite() の性能問題を修正しました。 (Tom Lane) (9.6)(9.5)(9.4)(9.3)(9.2)
- ts_rewrite() の入れ子になった NOT 演算子の扱いが修正されました。 (Tom Lane) (9.6)(9.5)(9.4)(9.3)(9.2)
- 遷移関数に array_append() を使うユーザ定義集約の速度が改善されました。 (Tom Lane) (9.6)(9.5)
- array_fill() が空配列を適切に扱えるように修正されました。 (Tom Lane) (9.6)(9.5)(9.4)(9.3)(9.2)
- レコードの配列を処理するときに、array_position() および array_positions() でクラッシュの可能性があり、修正されました。 (Junseok Yang) (9.6)(9.5)
- 内部実装関数 quote_literal_cstr() における 1 バイトのバッファオーバーランが修正されました。 (Heikki Linnakangas) (9.6)(9.5)(9.4)(9.3)(9.2)
- pg_start_backup() と pg_stop_backup() が複数並行で実行されるのが防止されました。 (Michael Paquier) (9.6)(9.5)(9.4)(9.3)(9.2)
- 何もしない AT TIME ZONE による変換を取り除こうとする書換えを使用しないようになりました。 (Tom Lane) (9.6)(9.5)
- 実際に何もしないわけではない interval 型から interval 型へのキャストを無効にしないようになりました。 (Tom Lane) (9.6)(9.5)(9.4)(9.3)(9.2)
- パラレルクエリに利用できるワーカ数が再スキャン中に減った場合のクラッシュが修正されました。 (Andreas Seltenreich) (9.6)
- パラレルワーカに GUC パラメータを送るときの障害が修正されました。 (Michael Paquier, Tom Lane) (9.6)(9.5)
- PREPARE コマンドで作られたプリペアドステートメントでもパラレルプランを得られるようになりました。 (Amit Kapila, Tobias Bussmann) (9.6)
- semi-join むけの誤ったパラレルプラン生成が修正されました。 (Tom Lane) (9.6)
- プランナのパラレル結合むけの値の種類数の見積が修正されました。 (Robert Haas) (9.6)
- プランナが初期プランやサブプランを含むプランノードをパラレル化しようとしないように修正されました。 (Tom Lane, Amit Kapila) (9.6)
- 外部テーブルオプションの変更により、キャッシュされたプランが確実に無効化されるようになりました。 (Amit Langote, Etsuro Fujita, Ashutosh Bapat) (9.6)(9.5)(9.4)(9.3)
- 定数の GROUP BY句 を伴うソートされた部分集約むけに生成されたプランが修正されました。 (Tom Lane) (9.6)
- CTE 参照を含む UNION ALL を処理する際に「ERROR: could not find plan for CTE "..."」エラーが出るのが修正されました。 (Tom Lane) (9.6)
- Material ノードを強制的にサブプランに加えるときの initplan の誤操作が修正されました。 (Tom Lane) (9.6)
- semi-join、anti-join に対する外部キーに基づく結合の選択率見積が修正されました。同様に継承の場合も修正されました。 (Tom Lane) (9.6)
- 拡張モジュールの設定テーブルであると印付けされたシーケンスのデータを出力するように pg_dump が修正されました。 (Michael Paquier) (9.6)
- pg_dump における ALTER DEFAULT PRIVILEGES ... REVOKE の誤操作が修正されました。 (Stephen Frost) (9.6)
- pg_dump が組み込み関数を使ったユーザ定義キャストとユーザ定義変換 (TRANSFORM) をダンプするように修正されました。 (Stephen Frost) (9.6)(9.5)(9.4)(9.3)(9.2)
- 「--create --if-exists」オプションを伴う pg_restoreが、アーカイブに認識できない DROP コマンドが含まれている場合に、よりよく動作するように修正されました。 (Tom Lane) (9.6)(9.5)(9.4)
- 遅いストレージ I/O であるときの pg_basebackup の転送レート制限が修正されました。 (Antonin Houska) (9.6)(9.5)(9.4)
- pg_basebackup でのシンボリックリンクされた pg_stat_tmp と pg_replslot サブディレクトリの扱いが修正されました。 (Magnus Hagander, Michael Paquier) (9.6)(9.5)(9.4)
- スタンバイサーバでの WAL ファイルを含めた pg_basebackup で失敗の可能性があり、修正されました。 (Amit Kapila, Robert Haas) (9.6)(9.5)(9.4)(9.3)(9.2)
- initdb が *_flush_after 設定について、正しいプラットフォーム固有のデフォルト値を postgresql.conf に書き入れるように改善されました。 (Fabien Coelho, Tom Lane) (9.6)
- 拡張された配列がドメインのチェック制約や CASE 実行で誤動作する可能性があり、修正されました。 (Tom Lane) (9.6)(9.5)
- 変数割り当て中にドメインのチェック制約が評価されるコンテクストで入れ子に使われる PL/pgSQL 関数について修正されました。 (Tom Lane) (9.6)(9.5)
- PL/Python むけに作成した Python の例外オブジェクトが、適切に参照カウントされるようになりました。 (Rafa de la Torre, Tom Lane) (9.6)(9.5)(9.4)(9.3)(9.2)
- PL/Tcl がカラム名に「.tupno」を含むテーブル上のトリガーをサポートするように修正されました。 (Tom Lane) (9.6)(9.5)(9.4)(9.3)(9.2)
- ~/.pgpass ファイルで Unix 上であっても DOS 形式の改行文字 (CR-LF) が使えるようになりました (Vik Fearing) (9.6)(9.5)(9.4)(9.3)(9.2)
- ecpg で「.」で終わるファイル名が与えられた場合の 1 バイトのバッファオーバーランが修正されました。 (Takayuki Tsunakawa) (9.6)(9.5)(9.4)(9.3)(9.2)
- psql の crosstabview で重複するデータに対する不正確なエラー報告が修正されました。 (Tom Lane) (9.6)
- ALTER DEFAULT PRIVILEGES に対する psql の TAB 補完が修正されました。 (Gilles Darold, Stephen Frost) (9.6)(9.5)(9.4)(9.3)(9.2)
- ALTER TABLE ... ALTER .. DROP ... に対する psql の TAB 補完が修正されました。 (Kyotaro Horiguchi) (9.6)
- psql が空か全て空白文字の PAGER 環境変数設定をページャ無しとして扱うようになりました。 (Tom Lane) (9.6)(9.5)(9.4)(9.3)(9.2)
- contrib/dblink の低レベル libpq エラーの報告が改善されました。 (Joe Conway) (9.6)(9.5)(9.4)(9.3)(9.2)
- contrib/dblink が contrib/postgres_fdw の外部サーバを接続オプションのソースとして使っているとき、無関係なサーバオプションを無視するようになりました。 (Corey Huinker) (9.6)(9.5)(9.4)(9.3)
- contrib/pageinspect の GIN インデックスむけ関数の移植性の問題が修正されました。 (Peter Eisentraut, Tom Lane) (9.6)(9.5)
- Windows で待機中にソケット読み取りイベントを見逃す可能性があり、修正されました。 (Amit Kapila) (9.6)
- Windows で環境変数の変更がデバッグオプションを有効にしてビルドされたシステム DLL に確実に伝搬するようになりました。 (Christian Ullrich) (9.6)(9.5)(9.4)(9.3)(9.2)
- タイムゾーンライブラリが IANA release tzcode2016j に同期されました。 (Tom Lane) (9.6)(9.5)(9.4)(9.3)(9.2)
- タイムゾーンデータを tzdata release 2016j に更新しました。 (9.6)(9.5)(9.4)(9.3)(9.2)
- Btree インデックスの VACUUM 処理中におけるスタンバイサーバ上の相互ロックが減りました。 (Simon Riggs) (9.5)(9.4)
- 制約違反エラーを報告する前に直列化可能性の競合を検査するようになりました。 (Thomas Munro) (9.5)(9.4)(9.3)(9.2)
- WAL セグメントを再読み込みする際の WAL ページヘッダ検証が修正されました。 (Takayuki Tsunakawa, Amit Kapila) (9.2)
以前にはインデックスされていなかった列にかかっているインデックスを作るのに CREATE INDEX CONCURRENTLY が使われていたなら、同時実行のトランザクションに更新された行は、誤ったインデックスエントリを受け取るおそれがありました。
CREATE INDEX CONCURRENTLY を使って作成されたインデックスを、バージョンアップ後に再作成することを推奨します。
バックエンドが自身の最も古いxminを知らせるときにこのスナップショットを考慮しておらず、潜在的に未だ必要なデータを削除する並列のバキューム操作を許していました。
この障害は接続時に「FATAL: cache lookup failed for relation 1255」を発生させました。
インデックスタプルを異なるページに移動するとき、BRIN の範囲マップページ (revmap page) むけに出力された WALレコードが不正でした。その WAL をリプレイすると、インデックスの関連する部分は使い物にならず、再計算を強いられます。
これまでは wal_level = minimal のときには省略されていましたが、実際にはこの場合でもクラッシュ後リカバリにて確実に正しく UNLOGGED テーブルを空に初期化するために必要でした。
これまでは子プロセス自動再起動の仕組みから抜け落ちていて、ホットスタンバイサーバでプロセスが非正常に終了すると終了したままになっていました。
スタンバイサーバで設定を on に変更して reload でなくサーバ再起動した場合に必要な初期化が行われませんでした。
autovacuum = off が設定されていて、XID 凍結が必要なテーブルがいくつかあって、それらのテーブルは既に autovacuum worker で処理中であるときに、問題の動作が生じます。
同期スタンバイを 0 個にしたい場合には設定値全体に空文字列を与えてください。
振る舞いが変更されたのは max_connections 設定による上限ではなく、ALTER ROLE ... CONNECTION LIMIT ... コマンドによる接続数上限です。
拡張モジュールのアップグレードスクリプトは要素オブジェクトを削除できなければいけませんが、serial 型に付随するシーケンスについてそれができませんでした。
修正により、オブジェクトが拡張モジュールに追加された時点の権限は、そのデフォルト権限と見做され、後の権限変更だけが以降の pg_dump 実行でダンプされるようになります。拡張モジュールに属するオブジェクトへの権限付与が正しくダンプされない問題が報告されていました。
これまで、ALTER TABLE ... ALTER TYPE を実行して、インデックス再作成が生じた場合、元のテーブルスペースではなく、その時点の default_tablespace 設定やデータベースのデフォルトに基づいたテーブルスペース上で再作成が行われました。さらに使用するテーブルスペースがシステムテーブルの情報と一致しないため、当該インデックスがアクセス不能になり、SQL 問い合わせに以下エラーが生じることがありました。
ERROR: could not open file "pg_tblspc/16567/PG_9.6_201701011/16456/16789": No such file or directory
その後のトリガ駆動時に奇妙な失敗をひき起こすおそれがあります。トリガが働く SQL 実行時に、以下のエラーが出る障害動作が報告されました。
ERROR: AfterTriggerSaveEvent() called outside of query
保留トリガイベントとはトランザクション末尾で処理をすることになっている延期されたトリガ処理を指します。以下の操作でエラーが出るようになりました。
db1=# BEGIN; db1=# SET CONSTRAINTS ALL DEFERRED ; db1=# INSERT INTO t15 VALUES (1); -- DEFERRABLEなトリガを駆動する操作 db1=# ALTER TABLE t15 DROP CONSTRAINT fk_t15_c1_fkey; ERROR: cannot ALTER TABLE t15 because it has pending trigger events
以前は制約の削除は成功し、COMMIT 時になって以下エラーが出ていました。
ERROR: could not find trigger NNN または ERROR: relation NNN has no triggers
エラーが発生することがありました。典型的には以下エラーが生じます。
ERROR: attribute N has wrong type
この場合 OID 列は通常のユーザ定義列と同様に扱われるべきでしたが、そうなっておらず、後の継承の変更で奇妙な振る舞いをひき起こしました。
(修正前の動作例: 親テーブルから列の除去は可能だが、OID 除去はエラーになっている) db1=# CREATE TABLE t17c (a int, b int) WITH """""""""""""""""""""""""""""""""""""""""""OIDS; db1""""""""""""""""""""""""""""""""""""""""""" =# CREATE TABLE t17p (a int, b int) WITH """""""""""""""""""""""""""""""""""""""""""OIDS; db1""""""""""""""""""""""""""""""""""""""""""" =# ALTER TABLE t17c INHERIT t17p; db1=# ALTER TABLE t17p DROP a; db1=# ALTER TABLE t17p SET WITHOUT OIDS; ERROR: relation 16678 has non-inherited attribute "oid"
LIKE を伴ったときに作られるテーブルが WITH OIDS にならない場合がありました。
これまでは以下のように元のビュー問い合わせには適合しないオプションを与えたときにエラーが生じていました。
db1=# CREATE TABLE t19 (a int, b text); db1=# CREATE VIEW v19 AS SELECT null::int AS a; db1=# CREATE OR REPLACE VIEW v19 AS SELECT * FROM t19 WHERE a > 0 WITH CHECK OPTION; ERROR: WITH CHECK OPTION is supported only on automatically updatable views HINT: Views that do not select from a single table or view are not automatically updatable.
これまでイベントトリガに誤ったカタログ OID が報告されてました。
以下の関数呼び出しがエラーを出さず、NULL を返すようになります。
(修正前の動作例) db1=# SELECT pg_xact_commit_timestamp('1'::xid); ERROR: cannot retrieve commit timestamp for transaction 1 db1=# SELECT pg_xact_commit_timestamp('2'::xid); ERROR: cannot retrieve commit timestamp for transaction 2
症状としては、以下例のような問い合わせで、実際には問題ないにも拘らず「ERROR: ON CONFLICT is not supported ...」エラーが出ることです。
(修正前のエラー例) db1=# CREATE TABLE t22 (f1 int PRIMARY KEY, f2 text); db1=# CREATE VIEW v22 AS SELECT * FROM t22 WITH CASCADED CHECK OPTION; db1=# INSERT INTO v22 VALUES (1,'foo') ON CONFLICT (f1) DO UPDATE SET f2 = excluded.f2; ERROR: ON CONFLICT is not supported on table "v22" used as a catalog table LINE 1: insert into v22 values (1,'foo') on conflict (f1) do update ...
実際には列数上限の半分程度であるのにエラーが生じました。
(修正前の障害動作例) db1=# INSERT INTO t23 VALUES (<<...831個の値...>>) ON CONFLICT (id) DO UPDATE SET <<...830個の代入式...>>; ERROR: target lists can have at most 1664 entries
(障害動作例) db1=# CREATE TABLE t24 (c1 int, c2 int); db1=# ALTER TABLE t24 DROP c2; db1=# CREATE FUNCTION f24(do_update boolean) RETURNS void LANGUAGE sql VOLATILE AS $$ UPDATE t24 SET c1 = NULL WHERE do_update; $$; db1=# SELECT f24(false); ERROR: table row type and query-specified row type do not match DETAIL: Query provides a value for a dropped column at ordinal position 2. CONTEXT: SQL function "f24" statement 1
以下のような奇妙なエラーメッセージが生じていました。修正によりレコード型であることを認識するようになりました。
(障害動作例) db1=# CREATE TABLE t25 (id int primary key, c1 int, c2 int); db1=# INSERT INTO t25 VALUES (1, 100, 100); db1=# UPDATE t25 SET c1= t25.*; ERROR: UPDATE target count mismatch --- internal error (正しいエラー) ERROR: column "c1" is of type integer but expression is of type record
これまでは、最初のデータでデータ型修飾を決めていて、以下例のような奇妙なデータが作れてしまいました。
db1=# CREATE TABLE t26 AS SELECT * FROM ( VALUES ('ABCDE'::varchar(5)), ('01234567890') ) v (string); db1=# d t26 Table "public.t26" Column | Type | Modifiers --------+----------------------+----------- string | character varying(5) | db1=# SELECT * FROM t26; string ---------------------------------- ABCDE 01234567890 (2 rows)
本来はユニコードのサロゲートペアの先頭文字には末尾文字が続かなければいけませんが、先頭文字がユニコードリテラル(U&'....' や U&"....")で文字列末尾にあらわれた場合にチェック漏れがあり、データ投入等ができてしまいました。
(修正後に正しくエラーが出る例) db1=# INSERT INTO t27 VALUES (U&'d80d'); ERROR: invalid Unicode surrogate pair at or near "'" LINE 1: INSERT INTO t27 VALUES (U&'d80d');
そのような SQL 処理でクラッシュをひき起こすことがありました。
フレーズ演算子と組み合わせて &、|、! 演算子が使われている場合に、これまで奇妙な検索結果を返したり、クラッシュをひき起こすことがありました。
誤動作例を示します。一つ目は q の後に x z または y z が続くという意味なので、True にならなければいけません。二つ目は x 以外の後に y が続くパターンが含まれるかどうかですから True にならなければいけません。
(修正前の誤った動作例) db1=# SELECT to_tsvector('simple', 'q y z') @@ 'q <-> (x | y <-> z)'; ?column? ---------- f (1 row) db1=# SELECT to_tsvector('simple', 'x y q y') @@ '!x <-> y'; ?column? ---------- f (1 row)
これまで GIN インデックス検索ではマッチしましたが、シーケンシャルスキャンや GiST インデックス検索の際にはマッチしませんでした。
(修正前の例: 以下は t が返るようになります) db1=# SELECT to_tsvector('simple', '') @@ '!foo'; ?column? ---------- f (1 row)
(クラッシュが起きる例) db1=# SELECT ts_rewrite(to_tsquery('5 & (6 | 5)'), to_tsquery('5'), to_tsquery('')); NOTICE: text-search query doesn't contain lexemes: "" server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed.
引数に与える内容の規模が大きいと非常に遅くなるのが改善されました。また、処理中に中断できる箇所を増やしました。
間違った結果を返すことがありました。
(修正前の誤った結果) db1=# SELECT ts_rewrite( ts_rewrite('new & !york ', 'york', '!jersey'), 'jersey', 'mexico'); ts_rewrite ------------------- 'new' & !'mexico' (1 row) (正しい結果) ts_rewrite -------------------- 'new' & !!'mexico' (1 row)
以下のように array_fill() で長さゼロの空配列を作った結果、0 次元になっておらず '{}' と一致しない動作がありました。
(修正前の誤った動作例) db1=# SELECT a, a = '{}' AS is_eq, array_dims(a) FROM (SELECT array_fill(NULL::int, array[0]) as a) ss; a | is_eq | array_dims ----+-------+------------ {} | f | [1:0] (1 row)
(クラッシュをひき起こす例) db1=# SELECT array_position(ids, (1, 1)), array_positions(ids, (1, 1)) FROM (VALUES (ARRAY[(0, 0), (1, 1)]), (ARRAY[(1, 1)]) ) AS f (ids);
quote_literal_cstr() は format() 関数などで使われています。入力がシングルクオートとバックスラッシュだけから構成されている場合にのみ発生します。
以下のような不明な警告が出ることがありました。
db1=# SELECT format('%L', E'¥¥'); WARNING: detected write past chunk end in ExprContext 0x55c65ff98fa8 format -------- E'¥¥' (1 row)
本修正は、これらの関数の並列実行が試みられた際に、アサートエラーや不正な動作が生じるのを回避します。
何もしない AT TIME ZONE による変換とは、元々 UTC での値が格納された timestamp with time zone 型のデータに AT TIME ZONE 'utc' として、timestamp without time zone 型のデータに変換する、などを指します。問い合わせで不適切なインデックス利用が生じて誤った結果が返る可能性がありました。
一部ケースで、低位フィールドをゼロにすべきキャストについて誤って何もしなくてよいと見なされました。
(9.4.10 で報告された誤動作例 - 秒以下が切り捨てられるのが正しい) db1=# SELECT x.y :: interval day to minute, (interval '02:47:15.375721') :: interval day to minute FROM (VALUES (interval '02:47:15.375721')) x (y); y | interval -----------------+---------- 02:47:15.375721 | 02:47:00
set_config() 関数をパラレル実行させた際にクラッシュする事例が報告されました。
これまでは PostgreSQL プロトコルの Parse メッセージで作られたプリペアドステートメントだけ対応していました。
... WHERE EXISTS (...) 等を使った semi-join をともなう SQL において、パラレルプランで実行した場合に誤った結果が返ることがありました。
これらの見積が確実に(全体の値ではなく)各ワーカごとの予測行数を反映するようにされました。
比較的複雑なサブクエリを伴う SQL で、パラレル実行させた場合にアサートエラーが生じる例が報告されていました。
「ALTER FOREIGN TABLE ... OPTIONS (...)」で外部テーブルが参照するリモートのスキーマ、テーブルを変えた場合にもプランが更新されませんでした。
(障害動作例) db1=# CREATE FOREIGN TABLE ft (c1 integer, c2 varchar) SERVER link_server OPTIONS (schema_name 's1', table_name 't1'); db1=# PREPARE stmt_ft AS SELECT c1,c2 FROM ft; db1=# EXECUTE stmt_ft; c1 | c2 ----+------- 1 | s1.lt (1 row) db1=# ALTER FOREIGN TABLE ft OPTIONS (SET schema_name 's2', SET table_name 'lt'); db1=# ANALYZE; db1=# EXPLAIN (COSTS OFF, VERBOSE) EXECUTE stmt_ft; QUERY PLAN ---------------------------------------- Foreign Scan on public.ft Output: c1, c2 Remote SQL: SELECT c1, c2 FROM s1.lt (3 rows)
そのような SQL 実行に対して奇妙なプランナエラー「ERROR: invalid attnum: 0」が出る例が報告されました。
(障害動作例: 1 と 2 の最大値なので 2 が返るのが正しい) db1=# WITH i(x) AS (VALUES (1::int)), j(y) AS (VALUES (2::int)) SELECT max(x) FROM (SELECT x FROM i UNION ALL SELECT y FROM j) b; ERROR: could not find plan for CTE "i"
以下の形状の SQL で障害が報告されました。
SELECT 1 IN (SELECT (SELECT 1)); SELECT 1 = ANY (SELECT (SELECT 1)); SELECT 1 = ALL (SELECT (SELECT 1));
本障害により典型的にはエラー「ERROR: plan should not reference subplan's variable」が生じます。
外部キーを考慮にいれた新たなコードは、これらの場合には見積の劣化を引き起こしていました。
シーケンスについて、pg_extension_config_dump() 関数で印をつけてもダンプで出力されない動作になっていました。
ALTER DEFAULT PRIVILEGES が通常の状態よりも権限を減らすのに使われている場合に pg_dump が必要な REVOKE コマンドを出力しませんでした。
(通常より権限を減らす使い方の例 - これらが正しくダンプされません) ALTER DEFAULT PRIVILEGES FOR ROLE myrole REVOKE SELECT ON TABLES FROM myrole; ALTER DEFAULT PRIVILEGES FOR ROLE myrole REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;
これは現時点の具体的な障害を修正するわけではありませんが、将来より後のバージョンの pg_dump で生成されたアーカイブを扱う際の振る舞いを改善すると考えられます。
ストレージ I/O が一時的に指定の転送レート制限よりも著しく遅かった場合、計算がオーバーフローして、残りの実行において転送レート制限が事実上使えませんでした。
これらがシンボリックリンクであるとき誤った tar ヘッダが作られていました。
本来必要な分よりも手前の WALを要求し、それが得られないため失敗する可能性がありました。
#bgwriter_flush_after = 0 # 0 disables, # default is 512kB on linux, 0 otherwise #checkpoint_flush_after = 0 # 0 disables, # default is 256kB on linux, 0 otherwise
PL/pgSQL 関数がこのような文脈で続く操作で保持される必要のある配列値を変更あるいは削除して誤動作する可能性がありました。
(報告された障害発生例: 奇妙なエラーが生じています) db1=# CREATE FUNCTION x_domain_test_check(integer[]) RETURNS boolean AS $$ BEGIN RETURN true; END; $$ LANGUAGE plpgsql IMMUTABLE; db1=# CREATE DOMAIN x_domain_test AS integer[] CHECK(x_domain_test_check(VALUE)); db1=# DO $$ declare v_test x_domain_test; begin v_test := '{}'::x_domain_test; v_test := v_test || 1; end; $$ LANGUAGE plpgsql; ERROR: SPI_connect failed: SPI_ERROR_CONNECT CONTEXT: PL/pgSQL function inline_code_block line 5 at assignment
(CASEの誤動作例: 以下を繰り返し実行すると CASE で 'right' 以外が返ることがありました) BEGIN; CREATE DOMAIN arrdomain AS int[]; CREATE FUNCTION make_ad(int,int) RETURNS arrdomain AS $$ declare x arrdomain; begin x := array[$1,$2]; return x; end $$ LANGUAGE PLPGSQL VOLATILE; CREATE FUNCTION ad_eq(arrdomain, arrdomain) RETURNS boolean AS $$ begin return array_eq($1, $2); end $$ LANGUAGE plpgsql; CREATE OPERATOR = (procedure = ad_eq, leftarg = arrdomain, rightarg = arrdomain); SELECT CASE make_ad(1,2) WHEN array[2,4]::arrdomain THEN 'wrong' WHEN array[2,5]::arrdomain THEN 'still wrong' WHEN array[1,2]::arrdomain THEN 'right' END; ROLLBACK;
PL/pgSQL の実行で「ERROR: SPI_connect failed: SPI_ERROR_CONNECT」が生じることがありました。
これにより Python のガベージコレクションの後にオブジェクトが使われてクラッシュが生じるのを防ぎます。
「.tupno」カラムは PL/Tcl で問い合わせ結果の現在行番号が格納される列として使われていて、その動作と調和させました。テーブルのカラム名に無い場合には「.tupno」は引き続き結果行番号格納用に使われます。
この変更は同じパスワードファイルを Unix と Windows で使うのを容易にします。
「crosstabview: query result contains multiple data values for row "1", column "9"」といったエラーが出る際に、実際に重複しているのとは異なる行・列が示されることがありました。
これまではこのような環境変数設定を与えてページャが起動されるケースになると何も出力されませんでした。
これまでは、例えば out-of-memoryエラーが "unknown error" となっていました。
これまでは外部サーバオブジェクトがオプションを持っていて、それが「updatable 'true'」など libpq 接続オプション以外であるとき、以下のようなエラーが生じていました。
db1=# SELECT * FROM dblink('fdw_server', 'SELECT 1') as t(x integer); ERROR: could not establish connection DETAIL: invalid connection option "updatable"
ia64 や sparc64 などでクラッシュが生じる可能性がありました。
ほとんどの場合にこれは無害ですが、pldebugger 拡張モジュールを使った際にハングアップをひき起こすことが知られています。
多数の問題が修正されています。最も重要なものとしては、対象ディレクトリがハードリンクをサポートしない場合はタイムゾーンデータ導入に失敗する問題がありました。
北キプロス(新タイムゾーン Asia/Famagusta 追加)、ロシア(新タイムゾーン Europe/Saratov 追加)、トンガ、Antarctica/Casey における夏時間法の変更と、イタリア、カザフスタン、マルタ、パレスチナにおける歴史的修正、トンガにおける数値によるゾーン略記法を優先する変更が含まれます。
本変更は、このような操作のリプレイ時にしばしば発生する顕著なレプリケーション遅延を回避します。
シリアライザブルトランザクション隔離を使うとき、同時実行トランザクションによる全てのエラーは直列化失敗と表明されることが望まれます。これによりアプリケーションにリトライして成功するかもしれないと示すことができます。
しかしながら、並列の行挿入によるキー重複違反のエラーが出てしまうケースがあるため、上記は確実には実現できていませんでした。
本変更は、アプリケーションがトランザクション内より手前で明示的に衝突するキーの存在(およびそれが見つからないことを)検査しているのであれば、そのようなエラーを確実に直列化失敗のエラーとして報告されるようにします。
以下のように実行したときに「ERROR: duplicate key value violates ...」ではなく、確実に「ERROR: could not serialize access ...」がでるようにしたということです。
[[トランザクション1]] [[トランザクション2]] db1=# START TRANSACTION ISOLATION LEVEL SERIALIZABLE; db1=# START TRANSACTION ISOLATION LEVEL SERIALIZABLE; db1=# SELECT * FROM t1 WHERE id = 1; id | v ----+--- (0 rows) db1=# SELECT * FROM t1 WHERE id = 1; id | v ----+--- (0 rows) db1=# INSERT INTO t1 (id) VALUES (1); db1=# INSERT INTO t1 (id) VALUES (1); (ブロックされる) db1=# COMMIT; ERROR: could not serialize access due to read/write dependencies among transactions (一意制約違反でなく、直列化失敗エラーになる)
稀な場合に、偽の(すなわち実際にはデータは壊れていない状況で)「out-of-sequence TLI」エラーがリカバリ中に報告される可能性がありました。