このリリースは 11.18 からの修正リリース(2023年 2月 9日リリース)です。
11.X からのアップデートではダンプ、リストアは不要です。
しかしながら、11.14 よりも前のバージョンからアップデートする場合には、11.14 のリリース情報も参照してください。
PostgreSQL 11.18 から 11.19 への変更点
15.2、14.7、13.10、12.14、11.19 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。
- libpq は GSSAPIトランスポート暗号化の開始に失敗した後にメモリ内容をリークする可能性があり、修正されました。 (Jacob Champion) (15)(14)(13)(12)
- パーティションテーブルまたは継承ツリーの UPDATE中に、子テーブルで更新する必要がある GENERATED列の計算が修正されました。 (Amit Langote, Tom Lane) (15)(14)(13)
- MERGE で GENERATED列の計算が失敗する可能性があったのが修正されました。 (Dean Rasheed) (15)
- MERGE で到達不可能な WHEN句に対するチェックが修正されました。 (Dean Rasheed) (15)
- MERGE のルール検出テストが修正されました。 (Dean Rasheed) (15)
- MERGE では「DO NOTHING」アクションを処理された行数として数えないようになりました。 (Álvaro Herrera) (15)
- 「WITH RECURSIVE ... CYCLE」という共通テーブル式(CTE) が出力列にアクセスできるようになりました。 (Tom Lane) (15)(14)
- 外部テーブルへのバルクインサートを行なう際の保留中のインサート処理について修正されました。 (Etsuro Fujita) (15)(14)
- その時点では有効でないインデックスに REPLICA IDENTITY が設定できるようになりました。 (Tom Lane) (15)(14)(13)(12)(11)
- 複数行の VALUESリストから INSERT を実行するルールにおける、DEFAULT の処理が修正されました。 (Dean Rasheed) (15)(14)(13)(12)(11)
- jsonpath の存在チェックで未定義変数の使用が拒否されるようになりました。 (Alexander Korotkov, David G. Johnston) (15)(14)(13)(12)
- TOAST格納された添え字の値を扱えるように、jsonb の添え字処理が修正されました。 (Tom Lane, David G. Johnston) (15)(14)
- 並列ハッシュ結合における稀な場合のデータ破損が修正されました。 (Dmitry Astapov) (15)(14)(13)(12)(11)
- checkpoint_completion_target のデフォルト以外の設定を尊重するようになりました。 (Bharath Rupireddy) (15)(14)(13)(12)(11)
- recovery_target_xid モードでログに正しい終了タイムスタンプが記録されるようになりました。 (Tom Lane) (15)(14)(13)(12)(11)
- バッファリングされたファイル読み込みの失敗に対するエラー報告が改善されました。 (Peter Eisentraut) (15)(14)(13)
- int2vector と oidvector で要素数の恣意的な上限が取り除かれました。 (Tom Lane) (15)
- 拡張問い合わせプロトコルで、パイプラインを実行していた場合、ANALYZE の後に即時コミットをしないようになりました。 (Tom Lane) (15)(14)(13)(12)(11)
- 間違った長さのキャンセルリクエストパケットを拒否するようになりました。 (Andrey Borodin) (15)(14)(13)(12)(11)
- ウィンドウ関数の実行条件式に対するプランナの前処理の誤りが修正されました。 (Richard Guo, David Rowley) (15)
- ウィンドウ関数の実行条件式を実行する際に、無効な領域へのポインタアクセスが修正されました。 (David Rowley) (15)
- サブクエリのプルアップにおいて、再帰呼び出しやループに対する防御機構が追加されました。 (Tom Lane) (15)(14)(13)(12)(11)
- Memoizeノードと、パーティション横断の結合やパラメタ化された入れ子ループを組み合わたのときの、プランナの問題が修正されました。 (Richard Guo) (15)(14)
- パーティション横断の結合で、各パーティションに対するプラン生成の失敗に寛容になるように修正されました。 (Tom Lane) (15)(14)(13)(12)(11)
- get_actual_variable_range によって実行されるクリーンナップ作業の量が制限されるようになりました。 (Simon Riggs) (15)(14)(13)(12)(11)
- リレーションの relkind が変わった時、統計計算が混乱してしまった問題が防止されました。 (Andres Freund) (15)
- 括弧で囲まれた「AT TIME ZONE」構文の表示が修正されました。 (Tom Lane) (15)(14)
- SQL関数でユーティリティコマンドに対するキャッシュされたパースツリーの誤った上書きを防止するようになりました。 (Tom Lane, Daniel Gustafsson) (15)(14)
- 全文検索の問い合わせの実行がフレーズ一致を処理しているときに確実にキャンセルできるようになりました。 (Tom Lane) (15)(14)(13)(12)(11)
- 非決定的な照合順序を持つ文字列のハッシュ作成におけるメモリリークが修正されました。 (Jeff Davis) (15)(14)(13)(12)
- DROP DATABASE と論理レプリケーションワーカプロセスと間のデッドロックが修正されました。 (Hou Zhijie) (15)(14)
- レプリケーション接続の試行に失敗した後に、libpq の接続オブジェクトをクリーンアップするようになりました。 (Andres Freund) (15)(14)(13)(12)(11)
- ホットスタンバイサーバで、プライマリ上でアクティブと知られている XID を調べる処理負荷が軽減されました。 (Simon Riggs, Michail Nikolaev) (15)(14)(13)(12)(11)
- カタログの最も古い xmin を決定する際に、無効な論理レプリケーションスロットを無視するようになりました。 (Sirisha Chamarthi) (15)(14)(13)
- 論理デコーディングで、トランザクションのクラッシュが検出されたときにリモートノードに通知するようになりました。 (Hou Zhijie) (15)(14)
- 論理デコーディングにおける未初期化メモリの使用が修正されました。 (Masahiko Sawada) (15)(14)(13)(12)(11)
- 論理デコーディングのコンテキスト作成に際して共有状態を更新している間、スピンロックを取得するようになりました。 (Masahiko Sawada) (15)
- pgoutput レプリケーションプラグインが、テーブルレプリケーションの列一覧に列挙されていない列を送信しないよう修正されました。 (Hou Zhijie) (15)
- ハッシュインデックスのページ分割操作の WALリプレイ時に稀に発生する「PANIC: failed to acquire cleanup lock」を回避するようになりました。 (Robert Haas) (15)(14)(13)(12)(11)
- WALリプレイ中にその全可視ビットを設定する際に、ヒープページの LSN が前進するようになりました。 (Jeff Davis) (15)(14)(13)(12)(11)
- int64_div_fast_to_numeric() がより広い範囲の入力に対して動作するように修正されました。 (Dean Rasheed) (15)(14)
- WaitEventSetロジックにおける潜在的なバッファオーバーランの問題が修正されました。 (Thomas Munro) (15)(14)(13)(12)(11)
- 32-bitビルドで共有メモリにアクセスする際に、名目上未定義の挙動を回避するようになりました。 (Andres Freund) (15)(14)(13)(12)(11)
- BRIN minmax-multi 演算子クラスのアサート失敗が修正されました。 (Tomas Vondra) (15)(14)
- 不要な RESULT RTE 最適化ロジックでの不完全なアサートが削除されました。 (Tom Lane) (15)(14)(13)(12)
- ACLチェックに対する「ERROR: cache lookup failed ..」エラーメッセージのコピーアンドペースト誤りが修正されました。 (Justin Pryzby) (15)(14)(13)(12)(11)
- pg_basebackup で多数のテーブルスペース対応付けを指定した場合に、壊れたテーブル空間マップ(tablespace_map)ファイルを生成する可能性があり、修正されました。 (Antonin Houska) (15)
- pg_dump で --if-exists オプションを使用したときに、無害な警告が出ないようになりました。 (Tom Lane) (15)
- psqlメタコマンドの \sf と \ef がSQL標準の関数本体を持つ SQL言語関数を処理できるように修正されました。 (Tom Lane) (15)(14)
- psql で ALTER FUNCTION/PROCEDURE/ROUTINE ... SET SCHEMA のタブ補完が修正されました。 (Dean Rasheed) (15)(14)(13)(12)(11)
- contrib/pageinspectモジュールが更新され、そのディスクアクセス機能を「PARALLEL RESTRICTED(パラレル制限)」としてマークするようになりました。 (Tom Lane) (15)
- contrib/segモジュールで seg型の値として入力した数が 127桁を超える場合に、クラッシュしたり、ごみデータを出力したりすることがあり、修正されました。 (Tom Lane) (15)(14)(13)(12)(11)
- Microsoft Visual Studio 2013 でのビルドが修正されました。 (Tom Lane) (15)(14)(13)(12)
- Strawberry Perl 5.30. 以上を使用して、MSVC で PL/Perl をビルドする際のコンパイルエラーが修正されました。 (Andrew Dunstan) (15)(14)(13)(12)(11)
- MSVC でビルドされた PL/Perl と gcc でビルドされた Perlライブラリの不一致が修正されました。 (Andrew Dunstan) (15)(14)(13)(12)(11)
- Perl のヘッダファイルからのコンパイラ警告が抑制されました。 (Andres Freund) (15)(14)(13)(12)(11)
- pg_waldump が未使用の静的インライン関数を破棄しないコンパイラでビルドされるように、修正されました。 (Tom Lane) (15)(14)(13)(12)(11)
- タイムゾーンデータファイルが tzdata release 2022g に更新されました。グリーンランドとメキシコの夏時間法の変更に加え、カナダ北部、コロンビア、およびシンガポールの歴史的修正が適用されました。 (15)(14)(13)(12)(11)
- リレーションキャッシュエントリの rd_smgrポインタの安全でない使用を防ぐようになりました。 (Amul Sul) (14)(13)(12)(11)
- pg_dump で、検査対象のテーブルをロックする前に安全でないサーバ関数を呼び出さないようになりました。 (Tom Lane, Gilles Darold) (14)(13)(12)(11)
- VACUUM実行の最後での「ERROR: wrong tuple length」の発生が防止されました。 (Ashwin Agrawal, Junfeng Yang) (13)(12)
- contrib/sepgsqlモジュールで、最近の libselinuxのバージョンでビルド時に出力されていた非推奨の警告が出ないように修正されました。 (Michael Paquier) (13)(12)(11)
- contrib/postgres_fdwモジュールの誤ったアサートが修正されました。 (Etsuro Fujita) (12)
改変されたサーバや信頼できない中間者は、Kerberos のトランスポート暗号化の確立中にゼロ終端されていない文字列を送信できます。次に libpq はその文字列とアプリケーションメモリ内の次のゼロバイトまでのバイトをエラー報告にコピーします。呼び出し側のアプリケーションがエラー報告に対して行なう処理によっては、アプリケーションのメモリ内容が漏洩する可能性がありました。また、メモリ終端を超えた読み取りによるクラッシュの可能性もわずかにありました。
サーバメッセージを適切にゼロ終端させることで修正されました。(CVE-2022-41862)
親テーブルに存在しない、または親列の生成式とは異なる依存関係を持つGENERATED列を更新できない問題が生じていました。誤った更新結果が生じるおそれがありました。
(修正前バージョンの誤動作例) db=# CREATE TABLE t2p (c1 int); db=# CREATE TABLE t2c (c2 int GENERATED ALWAYS AS (c1 + 1) STORED) INHERITS (t2p); db=# INSERT INTO t2c VALUES (10); db=# SELECT * FROM t2c; c1 | c2 ----+---- 10 | 11 (1 row) db=# UPDATE t2p SET c1 = c1 * 10; (以下で c2列は 101 が正しい) db=# SELECT * FROM t2c; c1 | c2 -----+---- 100 | 11 (1 row)
MERGE の最初の行単位アクションが UPDATE の場合、後続の INSERTアクションでは(UPDATEターゲット列のいずれにも依存していないため)UPDATEアクションで計算する必要がないとみなされた GENERATED列の計算に失敗しました。誤った更新結果が生じるおそれがありました。
(修正前バージョンの誤動作例) db=# CREATE TABLE t3 (id int PRIMARY KEY, c1 int, c2 int, g3 int GENERATED ALWAYS AS (c1 * 2) STORED, g4 int GENERATED ALWAYS AS (c2 * 2) STORED); db=# INSERT INTO t3 (id, c1, c2) VALUES (1, 5, 100); db=# SELECT * FROM t3; id | c1 | c2 | g3 | g4 ----+----+-----+----+----- 1 | 5 | 100 | 10 | 200 (1 row) db=# MERGE INTO t3 USING (VALUES (1,10),(2,20)) v(id, c1) ON t3.id = v.id WHEN MATCHED THEN UPDATE SET c1 = v.c1 WHEN NOT MATCHED THEN INSERT VALUES (v.id, v.c1, 200); (以下の id=1 の行の g3 は 20 が正しく、id=2 の行の g3、g4 は 40、400 が正しい) db=# SELECT * FROM t3; id | c1 | c2 | g3 | g4 ----+----+-----+--------+-------- 1 | 10 | 100 | 10 | 200 2 | 20 | 200 | *null* | *null* (2 rows)
無条件の WHEN句に続く WHEN句は下記のエラーで到達不能として拒否されるべきですが、このケースは常に検出されるわけではありませんでした。
ERROR: unreachable WHEN clause specified after unconditional WHEN clause
MERGE はルールのあるテーブルには対応していません。しかし、かつてルールを持っていて今は持っていないテーブルでも以下のエラーが生じていました。
ERROR: cannot execute MERGE on relation "..." DETAIL: MERGE is not supported for relations with rules.
これにより、コードの動作がドキュメントと一致するようになります。本障害および修正で変わるのは、MERGE 実行後の影響を受けた行数の出力値、すなわち、psql で「MERGE 10」などと表示され、libpq の PQcmdTuples(res) で取得できる値だけです。
これまで CTE内から SET句で指定した列を参照すると下記のエラーが生じていました。
(修正前バージョンのエラー発生例) db=# WITH RECURSIVE cte7(x, y) AS ( SELECT 0, 0 UNION ALL SELECT x, y FROM cte7 AS r WHERE r.is_cycle ) CYCLE x, y SET is_cycle USING path SELECT * FROM cte7; ERROR: cache lookup failed for type 0
保留中のインサートがすぐに外部テーブルラッパー(FDW)にフラッシュされず、BEFORE ROWトリガで本来見えるはずの行が見えないなど、論理的な不整合が発生することがありました。
本障害により、結果としてトリガによる誤った更新が生じる可能性がありました。
pg_dump が REPLICA IDENTITY と印付けされたパーティションインデックスをダンプする時、パーティションインデックスが有効となる前に「REPLICA IDENTITY」を適用するコマンド実行順で生成され、リストア失敗の原因となっていました。 この順序で実行することを禁止する正当な理由はないと判断され、許可するようになりました。インデックスが有効になるまで、REPLICA IDENTITY の印付けは何の効果も持ちません。
DEFAULT指定箇所を適切なデフォルト値の式に置き換えられず、「ERROR: unrecognized node type」が発生することがありました。
(修正前バージョンの誤動作例) db=# CREATE TABLE t10 (val int); db=# INSERT INTO t10 VALUES (100); db=# CREATE TABLE t10_log (ts timestamptz DEFAULT now(), val int, dsc text); db=# CREATE RULE r10 AS ON UPDATE TO t10 DO ALSO INSERT INTO t10_log VALUES (DEFAULT, OLD.val, 'old'), (DEFAULT, NEW.val, 'new'); db=# UPDATE t10 SET val = 101 WHERE val = 100; ERROR: unrecognized node type: 148
jsonpath の一致演算子ではパスパターンに未定義の変数があるとエラーになりますが、存在演算子ではエラーや警告を出さずに一致するものとして扱っていました。
(正しい動作) db=# SELECT jsonb_path_match('[{"a": 1}]', '$undefined_var'); ERROR: could not find jsonpath variable "undefined_var" (修正前バージョンの誤動作例、jsonb_path_match と同様にエラーとなるべき) db=# SELECT jsonb_path_exists('[{"a": 1}]', '$undefined_var'); jsonb_path_exists ------------------- t (1 row)
テーブルから直接フェッチされた長いテキスト値を jsonb 添え字として使用すると、エラーを起こす可能性がありました。フェッチ(値の取り出し)では、たいてい一致する要素を見つけられません。この問題を引き起こすほどの長いキーはフィールドではおそらく稀ですが、代入ではガベージキーを使用して値を格納できました。
(修正前バージョンの誤動作例) db=# CREATE TABLE t12 (id text, test_json jsonb); db=# INSERT INTO t12 VALUES ('foo', '{"foo": "bar"}'); db=# INSERT INTO t12 SELECT s, ('{"' || s || '": "bar"}')::jsonb FROM repeat('longsub', 500) s; (添え字に対する値が見つけられない結果になる) db1=# SELECT substr(id, 1, 20), test_json[id] FROM t12; substr | test_json ----------------------+----------- foo | *null* longsublongsublongsu | *null* (2 rows)
一時ファイルに書き出される大きなタプルの最後のチャンクがちょうど 32760バイトである場合、境界バグにより破損する可能性がありました。典型的には後に問い合わせがデータ破損の症状でエラーを出します。例えば(何らかデータ長を示す部分の値が壊れていることによる)「ERROR: XX000: invalid memory alloc request size 1702125924」が出るケースが報告されました。
ここでのデータ破損はメモリ上や一時ファイルで生じるものです。しかし、更新をする並列問い合わせでデータ破損を含む処理がエラーを起こさずに実行されてしまう可能性が無いとは確認されていません。
checkpoint_completion_target の変更後に内部状態が更新されなかったため、特に設定を reload で変更した場合、チェックポイント I/O の実行が設定値に基づいて期待されるよりも高速または低速になることがありました。
recovery_target_inclusive = "off" で recovery_target_xid 設定に基づいてリカバリを終了すると「LOG: recovery stopping before ... transaction」のログメッセージに誤ったタイムスタンプ(常に 2000-01-01)が出力されました。
短くしか読めなかった場合について正しく報告するようになりました。不適切なエラーコードに基づくメッセージではなく、期待されたバイト数と読んだバイト数が出力されるようになります。ロジカルレプリケーションやベースバックアップに関するコードで修正が適用されました。
以前は、これらの型の入力関数は 100 以上の要素を拒否してきました。論理レプリケーションの列をリスト指定できる仕様の導入に伴って、int2vector が最大で 1600列分の要素を受け付ける必要が生じました。
列数の多いテーブルに対して、論理レプリケーションが「ERROR: int2vector has too many elements」エラーを出して、止まってしまう動作が報告されました。
明示的なトランザクション開始命令(BEGIN TRANSACTION など)が無い場合、ANALYZE は勝手にコミットしていました。これはパイプライン化された一連のコマンドの中では望ましくないと判断されました。
これまで、長さが短いキャンセルリクエストも処理されていて、割り当てられたバッファの最後を超えた読み込みが発生していました。理論的にはセグメンテーション違反が起きる可能性がありましたが、そのバッファはメモリ末尾にとても近いため、実際にはほとんど発生しません。良く起きることは、間違ったバックエンド PID やキャンセルコードを指摘するでたらめなログメッセージを出力してしまうことです。
本修正でキャンセルリクエストについても間違った長さであることを示す「LOG: invalid length of startup packet」が報告されるようになりました。
これにより「ERROR: WindowFunc not found in subplan target lists」のようなプランナのエラーが出力されていました。
実際には、実行条件の最適化は int8 を返すいくつかのウィンドウ関数にのみ適用されるので、32-bit でビルドされた時のみの問題です。
作りこまれた問い合わせにより、結果として深い再帰になって、サブクエリの平坦化を試みるのに不合理に長時間を費やす可能性がありました。
これに対する適切な修正は後方適用するには修正量が大きくなります。本修正では、スタックの深さチェックと、問い合わせをキャンセルするための割り込み検査を加えています。
本障害により、Memoize が利用可能なときでも使われない劣った実行計画や、場合よっては誤った実行計画が生じる可能性がありました。
本障害により「ERROR: could not devise a query plan for the given query」というエラーが生じることがありました。エラーを出すのではなく、パーティション横断の結合をしない実行計画を選択するようになりました。
get_actual_variable_range は最大値・最小値を調べる PostgreSQLの内部実装関数で、プランナで使われます。
プランナは、インデックスの最後に現れる大量のタプルを削除した後にこれらのインデックスエントリに killedビットをセットする膨大な仕事をしなければならないことがありました。
本修正で 1つのクエリでの処理量が 100 ヒープページに制限されました。最終的には全てのタプルの削除は必要ですが、これにより突然の大幅な性能低下は回避できます。
テーブルをビューに変更するとクラッシュやアサート失敗になる可能性がありました。
これは「AT TIME ZONE」の引数自体が式になっているルールやビューに対するダンプ/リストアの失敗をもたらしました。
(誤動作例、括弧が外れてしまっている) db=# CREATE VIEW v27 AS SELECT ('2022-12-01'::date + '1 day'::interval) AT TIME ZONE 'Europe/Paris'; db=# SELECT pg_catalog.pg_get_viewdef('v27'::regclass, true); pg_get_viewdef ------------------------------------------------------------------------------------------------- SELECT ('2022-12-01'::date + '1 day'::interval AT TIME ZONE 'Europe/Paris'::text) AS timezone; (1 row)
SQL言語の関数が同じユーティリティコマンドを 1つの問い合わせの中で複数回実行した場合、クラッシュやアサート失敗、「ERROR: unrecognized node type: ..」のような奇妙なエラーが引き起こされる可能性がありました。
(アサート失敗が報告されたSQL実行例) db=# CREATE FUNCTION f28() RETURNS INT LANGUAGE SQL AS $$ CREATE TABLE t28 (col0 INT CHECK ('x' = 'x')); SELECT 1; $$; db=# SELECT f28() FROM (VALUES (1), (1)) AS a0;
これは、ワーカで論理レプリケーションスロットを作成する際に、割り込みをブロックするという不用意な選択によって引き起こされていました。
バージョン15 では検出されないデッドロックをもたらす可能性がありました。バージョン14 ではデッドロックは観測されていませんが、ネットワークI/O を待っている間に割り込みをブロックすることは、やはり望ましくありません。
以前のコードでは接続オブジェクトをリークしていました。 バックグラウンドのコードパスでは呼び出し元のプロセスが終了してしまうので無害です。 しかし、CREATE SUBSCRIPTION のようなコマンドでは、このような失敗により、セッション内での小さなメモリリークが発生していました。
KnownAssignedXids配列のクリーンアップが不十分な場合、特にスタンバイ側で max_connections が大きな値に設定されている場合、性能が低下する可能性がありました。
レプリケーションスロットは、max_slot_wal_keep_size を超過して無効となった後も、システムカタログ内のデッドタプルのクリーンアップを妨げることができました。そのため、レプリケーションの消費者に障害が発生すると、カタログが際限なく肥大化する可能性がありました。
サーバ再起動の後、再起動の直前に発生したトランザクションの変更を再ストリームします。 これらのトランザクションのいくつかは、完了しませんでした。理由は、1つのトランザクションが完了しなかったことに気づいたとき、関連するデコーディング状態をそのサーバでは捨てますが、それについてサブスクライバに伝えていなかったからです。そのため、サブスクライバは、次に再起動するまで、無駄なストリーミングファイルを保持することになっていました。
いくつかのケースで論理デコードの再開時に解放済の XID データの再利用を試み、予測不可能な動作を引き起こすことがありました。
2フェーズトランザクションに関するデータを更新する際に、適切なロックを取得していなかったため、他プロセスから不整合データを見られる可能性がありました。
UPDATE と DELETE のイベントは設定された列一覧に注意を払わないため、予想以上に多くのデータを送信していました。 この問題はレシーバが組み込みの論理レプリケーションコードである場合は発生しませんが、他のレシーバを混乱させる可能性があり、いずれにしてもネットワーク帯域幅を無駄にするものでした。
これを行わなかった場合、スタンバイサーバとプライマリサーバでページが異なる可能性があり、LSN が変更されるタイミングに関する他のいくつかの想定に反しました。 PostgreSQL自体に関する限り、これは理論的な危険性だけであるように思えますが、サードパーティツールを混乱させる可能性がありました。
この関数はその第2引数における一部の値で誤動作していました。 PostgreSQL本体ではそのような使用法は存在していませんが、外部モジュールでは明らかに危険でしたので、修正されました。
epollベースおよび kqueueベースでの実装は、その内部バッファのサイズが呼び出し元の出力バッファのサイズと異なる場合、カーネルにあまりにも多くのイベントを要求する可能性がありました。
このケースはリリース済みの PostgreSQL のバージョンでは発生しないことが知られていますが、この誤りは外部モジュールや将来のバグ修正にとって有害です。
clang の未定義動作サニタイザは、アラインメントが取れていないポインタの使用についてエラーを出します。これが非デバッグビルドで問題を起こす可能性は非常に低いですが、テストのために修正する価値があると判断されました。
このアサートは過度に厳密でした。アサート無しビルドでは無害です。
問い合わせ実行で予期せぬアサート失敗が報告されました。
原理的には、このエラーに到達することはありませんが、それらのいくつかは間違ったタイプのオブジェクトを報告していました(cache lookup failed for schema とすべきところがcache lookup failed for function となる等)。
これまで publicスキーマにデフォルト(pg_database_owner)以外の所有者がいる場合、pg_dump で --if-exists オプションを使用すると、ダンプ出力自体には問題はありませんが、以下のような警告メッセージが表示されていました。
pg_dump: 警告: 文"-- *not* dropping schema, since initdb creates it "中に IF EXISTS を挿入すべき場所が見つかりませんでした
pg_dump: warning: could not find where to insert IF EXISTS in statement "-- *not* dropping schema, since initdb creates it "
これらのコマンドは、SQL標準の構文を使用したときに関数本体の開始を誤認していました。
SQL標準の関数本体とは、文字列定数ではなく単一の RETURN 文やBEGIN ATOMIC ~ END のブロックで記述したものを指します。
セッションの一時テーブルは並列ワーカからアクセスできないため、これらの関数のいずれかを使用して一時テーブルを調べる場合に、パラレル実行で結果が取得できない可能性がありました。
以前のパッチでは、対象のすべてのプラットフォームで snprintf() に対応していると想定されていましたが、MSVC 2013 ではまだ完全に対応されていません。MSVC 2013 では sprintf() を使用するように戻されました。
このような組み合わせで、以前は「loadable library and perl binaries are mismatched」というエラーでPL/Perl のロードに失敗することがありました。
推奨しているコンパイラオプションは、Perl のヘッダファイルの最近のバージョンで構造についての警告を引き起こします。 gcc を使用する場合、プラグマを使用してこれらの警告を抑制することができます。
注目すべき点としては、新しいタイムゾーン America/Ciudad_Juarez が America/Ojinaga から分割されました。
rd_smgr は PostgreSQL内部実装における RelationData構造体のメンバ変数です。
必要に応じて再計算する関数で rd_smgr のすべての使用をラップすることにより、一連の操作で rd_smgr が有効であり続けるというさまざまな仮定を取り除きます。これにより、一連の処理の途中で予期しないキャッシュフラッシュが発生した場合に発生するバグが防止されました。
pg_dump は、調べているテーブルが同時に削除されると失敗する可能性のあるいくつかのサーバ関数を使用します。テーブルのプロパティを深く調べる前にアクセス共有ロックを取得し、ダンプするつもりのないテーブルにそのような関数を適用しないようにすることで、この種の失敗が回避されました。
これは、VACUUM が現在のデータベースの datfrozenxid値を更新する必要があり、datacl値が行外に押し出されるほどデータベースに大量の権限付与がある場合に、発生していました。
正常な外部テーブルへの問い合わせでアサート失敗することがありました。