このリリースは 8.4.20 からの修正リリース(2014/3/20リリース)です。
8.4.x からのアップデートではダンプ、リストアは不要です。
また、8.4.19 より前のバージョンからアップデートを行う場合は 8.4.19 に関する技術情報を参照してください。
PostgreSQL 8.4.20 から 8.4.21 への変更点
9.3.4、9.2.8、9.1.13、9.0.17、8.4.21 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。
- 更新済みタプルをロックする WALリプレイについて修正されました。(Andres Freund, Álvaro Herrera) (9.3)
- GIN の WALリプレイでページ破損リスクを完全に回避するようになりました。(Heikki Linnakangas) (9.3)(9.2)(9.1)(9.0)(8.4)
- NOTIFY を受け取る際のトランザクションコミット競合を防止するようになりました (Marko Tiikkaja) (9.3)(9.2)(9.1)(9.0)
- マテリアライズドビューが UPDATE、DELETE から参照できるようになりました。 (Michael Paquier) (9.3)
- 正規表現操作の素早いキャンセルができるようになりました。 (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)
- 単一要素の行に対し OVERLAPS を実行しようとする誤ったコードが除去されました。 (Joshua Yanovski) (9.3)(9.2)(9.1)(9.0)(8.4)
- クエリのデパーズ時に AccessShareLock 以上のロックを取らないように修正されました (Dean Rasheed) (9.3)(9.2)(9.1)(9.0)(8.4)
- 実行プラン作成時にインデックスの端点を確認する処理の性能が改善されました (Tom Lane) (9.3)(9.2)(9.1)(9.0)
- プランナが「値 IN ( リスト )」や「値 比較演算子 ANY ( 配列 )」という式で、右側が固定式なら、デフォルトの選択率見積処理を使わないようになりました (Tom Lane) (9.3)
- DROP DATABASE コマンドでデータベース毎の実行時統計情報ファイルを正しく削除するようになりました (Tomas Vondra) (9.3)
- walsenderプロセスが自身の負荷が高いときに不適切に切断してしまう障害が修正されました (Andres Freund, Heikki Linnakangas) (9.3)
- クライアントが pg_receivexlog であるとき、walsenderプロセスが正常停止に失敗するのが修正されました (Fujii Masao) (9.3)(9.2)(9.1)
- クラッシュリカバリ時に wal_level と hot_standby パラメータのチェックが正しく行われるように修正されました (Heikki Linnakangas) (9.3)(9.2)
- クラッシュリカバリにてホットスタンバイ接続が可能かの判定が修正されました (Heikki Linnakangas) (9.3)(9.2)(9.1)(9.0)
- 読み取り専用の設定パラメータ data_checksums が追加されました (Heikki Linnakangas) (9.3)
- ERROR でないログメッセージ出力中の割り込みが防止されました (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)
- PL/Perl で複合型データを返すときのメモリリークが修正されました (Alex Hunsaker) (9.3)(9.2)(9.1)
- psql でスクリプトから copy を実行する際のエラー行番号の誤りが修正されました (Kumar Rajeev Rastogi, Amit Khandekar) (9.3)(9.2)
- postgres_fdw 拡張モジュールが複数の結合条件を適切に扱えるように修正されました (Tom Lane) (9.3)
- Windows で時々生じる「could not reserve shared memory region」エラーを防ぐようになりました (MauMau) (9.3)(9.2)(9.1)(9.0)
- タイムゾーンデータが tzdata release 2014a に更新されました (Tom Lane) (9.3)(9.2)(9.1)(9.0)(8.4)
本障害により、更新された行がインデックススキャンで見つからず、インデックススキャンが使われるかどうかで一貫性のない問い合わせ結果が生じていました。本障害は、不適切な WALリプレイによって生じます。したがって、リカバリ中であるかスタンバイサーバである場合に発生します。
典型的には、外部キー制約で被参照行の更新と参照行の挿入が並行して行われるときに発生します。本障害により制約違反の行が挿入される可能性があります。
データ破損が生じるため、不具合の解消には、バージョンアップ後にスタンバイサーバの作り直しが必要となります。
本障害については PostgreSQL wiki に詳しい説明があります。
本障害により、理論的には GIN インデックスのメタページが壊れる可能性がありました。ただし、メタページは一般的な 512バイトのディスクセクタより小さいため、実際には問題は起きないと考えられます。
NOTIFY 送信者によって作られる最新データが見えるようになる前に、受信側の高速なクライアントが通知に反応するかもしれないシナリオを防ぎます。
以下のように DELETE、UPDATE 内で参照された場合にエラーが発生していました。
db=# CREATE TABLE base ( id int primary key ); db=# CREATE MATERIALIZED VIEW mv AS SELECT * FROM base; db=# CREATE TABLE d ( id int primary key ); db=# DELETE FROM d WHERE EXISTS ( SELECT * FROM mv WHERE mv.id = d.id ); ERROR: cannot lock rows in materialized view "mv"
本修正により、複雑な正規表現がバックエンドプロセスが割り込みできない状態で長時間固まってしまうケースを防止します。
OVERLAPS は、２組の日付時刻に対してのみ使用可能な演算子です。単一要素行の組に対する使用は SQL標準ではなく、ドキュメントにも記載されていません。以下に、正しい実行例、正しいエラー例、本障害のエラー例を示します。
(正しい実行例)
=# SELECT ROW (DATE '2013-01-12', DATE '2014-02-01') OVERLAPS
ROW (DATE '2011-10-01', DATE '2013-02-10');
overlaps
----------
t
(1 row)
※「ROW」は省略可能
(正しいエラー例)
=# SELECT ROW (DATE '2013-01-12', DATE '2014-02-01', DATE '2016-01-01')
OVERLAPS ROW (DATE '2011-10-01', DATE '2013-02-10', DATE '2015-01-01');
ERROR: wrong number of parameters on left side of OVERLAPS expression
(本障害の不適切なエラー例)
=# SELECT ROW (DATE '2014-02-01') OVERLAPS ROW (DATE '2011-10-01');
ERROR: unrecognized node type: 656
クエリのデパーズとは解析（パーズ）済みのデータから SQL を再構成する処理です。ビューやルールの定義を出力するときに使われます。典型的にはpg_dump や psql の d で行われる処理です。
pg_dump が「INSERT INTO t ... 」を含むルールのデパーズをするとき、 t テーブルに RowExclusiveLock が発生していました。これはUPDATE、DELETE、INSERT 実行時と同レベルのロックであり、pg_dump は参照のみ行うという一般的な理解に反する動作でした。
インデックス末尾に未コミット行が多数あるとき、本修正で大幅に性能改善されます。連番やタイムスタンプをキーとして行を追加しているときには、よくある状況です。
実行時統計情報は、稼動中は一時ファイル (stats_temp_directory で指定されたディレクトリ下のファイル) に、停止時には永続ファイル($PGDATA/pg_stat 以下のファイル) に書きこまれます。
本修正により永続ファイルの削除漏れを防ぎます。これまで誤って一時ファイルの方を削除しており、永続ファイルが残ってしまいました。
残っている不要な実行時統計情報ファイルを特定するには以下の SQL でデータベースの OID 番号を調べ、ファイル名の番号との対応づけを調べます(ただし、db_0.stat ファイルは特別であり、削除してはいけません)。
SELECT oid, datname FROM pg_database ORDER BY oid;
walsender は wal_sender_timeout 設定に基づき、クライアント（スタンバイサーバなど）に pingメッセージを送り、そのレスポンスを確認して、接続が有効かを判断します。
walsender は WALデータ送信で絶えず忙しい場合、クライアントへのpingメッセージ送信に失敗していました。にもかかわらず、レスポンスを期待しており、時間経過して応答が無いことで切断をしていました。
pg_receivexlog が接続している状態で、サーバプロセスを fastモードで停止させようとしても、wal sender process だけ残り、タイムアウトまで待たされて失敗していました。
$ pg_ctl stop -m fast waiting for server to shut down............................................................... failed pg_ctl: server does not shut down $ ps x PID TTY STAT TIME COMMAND 8489 pts/2 S 0:00 /home/postgres/pgsql/9.3.3/bin/postgres 8490 ? Ss 0:00 postgres: logger process 8498 pts/2 S 0:00 pg_receivexlog -h localhost -D . 8499 ? Ss 0:00 postgres: wal sender process postgres ::1(46481) stre :
最初はクラッシュリカバリ処理をする場合でも、その後にアーカイブリカバリをしたり、hot_standby アクセスを受け付けたりするのであれば、それに見合ったwal_level 設定が必要で、これらをチェックするように修正されています。
その後にアーカイブリカバリが続くクラッシュリカバリの場合で、既に可能な段階であるにもかかわらず、ホットスタンバイ接続が許されませんでした。
initdb 時にページチェックサムを有効にしたかどうかを true、false で示します。
syslog への出力途中で割り込みが発生し、割り込み処理中に syslog 出力が発生することで、デッドロック状態になってしまう可能性がありました。接続時にハングアップする障害が報告されていました。
複数の OUT パラメータを使う場合も該当します。
copy で外部ファイルを指定したときにその行数が含まれてしまっていました。
(例 t.tsv は 100行のデータ) $ cat scr.sql DELETE FROM t; copy t FROM 't.tsv' SELECT error_sql; $ psql -f scr.sql DELETE 100 psql:scr.sql:104: ERROR: column "error_sql" does not exist LINE 1: SELECT error_sql;
以下のように外部テーブルの結合にて複数の結合条件がある場合が該当します。
SELECT * FROM ft2 a, ft2 b WHERE a.c2 = 6 AND b.c1 = a.c1 AND a.c8 = 'foo' AND b.c7 = upper(a.c7); SELECT * FROM ft2 a, ft2 b WHERE a.c2 = 6 AND b.c1 = a.c1 AND a.c8 = 'foo' AND b.c7 = upper(a.c7);
アサート有効でビルドしている場合にアサート失敗をひき起こしていました。また、アサート無効である場合には、安全でない WHERE句がリモートサーバに送られてしまい、エラーや誤った応答をひき起こす可能性があります。
Windows 8 / 2012 Server で以下のようなメッセージがでて接続に失敗する例が報告されていました。アドレス空間配置のランダム化を無効にするビルドオプションを加えて対応しています。
LOG: could not reserve shared memory region (addr=...) for child ...
LOG: could not fork new process for connection: A blocking operation was
interrupted by a call to WSACancelBlockingCall.
フィジー、トルコの夏時間法の変更、イスラエル、ウクライナの歴史的変更が適用されています。