<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>PostgreSQL 11 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql-11/feed/index.xml" rel="self" type="application/rss+xml" />
	<link>https://www.sraoss.co.jp/tech-blog/</link>
	<description>OSS専門の技術ブログ。PostgreSQL、Zabbixを中心に10種類以上のOSSの解説、アップデート情報、運用ヒントを提供。</description>
	<lastBuildDate>Fri, 30 Oct 2026 08:28:47 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.3</generator>

<image>
	<url>https://www.sraoss.co.jp/tech-blog/wp-content/uploads/2018/07/blog-icon-150x150.png</url>
	<title>PostgreSQL 11 &#8211; SRA OSS Tech Blog</title>
	<link>https://www.sraoss.co.jp/tech-blog/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>PostgreSQL 11.22 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-22/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Mon, 27 Nov 2023 00:00:20 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.21]]></category>
		<category><![CDATA[PostgreSQL 11.22]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=13333</guid>

					<description><![CDATA[このリリースは 11.21 からの修正リリース（2023年 11月 9日リリース）です。 11.X からのアップデートではダンプ、リストアは不要です。 しかしながら、11.21 よりも前のバージョンからアップデートする場 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 11.21 からの修正リリース（2023年 11月 9日リリース）です。<br />
11.X からのアップデートではダンプ、リストアは不要です。</p>
<p>しかしながら、11.21 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/11-21/ ">11.21 のリリース情報</a>も参照してください。<br />
11.X バージョン系列は本リリースが最終リリースとなります。</p>
<p><span id="more-13333"></span></p>
<h3>PostgreSQL 11.21 から 11.22 への変更点</h3>
<p>15.5、14.10、13.13、12.17、11.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>DISTINCT を付けて "any" 型の引数をとる集約関数を実行するときに、不明なデータ型の引数の扱いが修正されました。  (Tom Lane) (16)(15)(14)(13)(12)(11)</li>
<p>
本障害により、実行時にテキスト型の値が不明なデータ型の値（即ち 0x00 で終わる文字列）として解釈されて、テキスト値に続くサーバメモリの露出をもたらす可能性がありました。(CVE-2023-5868)
</p>
<li>新たな配列次元を計算する時に整数オーバーフローを検知するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)(11)</li>
<p>
現在の配列範囲の外側にある配列の添え字に新たな要素を割り当てるとき、境界値ケースで検知されない整数オーバーフローが生じる可能性がありました。潜在的に任意コード実行の攻撃が可能なメモリ上書きや、サーバメモリ暴露が可能でした。(CVE-2023-5869)
</p>
<li>pg_signal_backend ロールがバックグラウンドワーカと autovacuum のプロセスにシグナル送信することを防ぐようになりました。  (Noah Misch, Jelte Fennema-Nio) (16)(15)(14)(13)(12)(11)</li>
<p>
ドキュメントでは pg_signal_backend はスーパーユーザ所有のプロセスにはシグナルを投げれないとされていますが、これらプロセスには送信可能でした。紐づくロールの ID が ゼロになっていたため、スーパーユーザ所有でないと見做されていました。これらをスーパーユーザ所有として扱うように修正されました。
</p>
<p>
PostgreSQL本体コードの範囲ではセキュリティ影響は軽微です。しかし、バックグラウンドワーカを使う拡張が脆弱になるかもしれません。(CVE-2023-5870)
</p>
<li>GiSTインデックス作成で再帰的なページ分割中の誤動作が修正されました。  (Heikki Linnakangas) (16)(15)(14)(13)(12)</li>
<p>
ページのダウンリンク位置が不正確に追跡される場合について修正されて、そのような状態から復旧できるロジックが導入されました。この誤りはその後のインデックス検索で誤った問い合わせ結果をもたらします。マイナーバージョンアップ後に GiSTインデックスを再作成することを推奨します。
</p>
<li>interval型の列に対する Btreeインデックスエントリの重複排除が防止されました。  (Noah Misch) (16)(15)(14)(13)</li>
<p>
interval型には「24:00:00」と「1 day」のように、区別できるけれども比較すると等しい値があります。これは Btree 重複排除における前提を破ります。そのため、interval型の列は重複排除の対象外とする必要がありました。この見落としにより index only スキャンで誤った問い合わせ結果が返る可能性がありました。さらに、amcheck がほぼ全てのこのようなインデックスをエラー報告するように改定されました。
</p>
<p>
マイナーバージョンアップ後に interval型列の btreeインデックスは再作成すべきです。
</p>
<li>datetime_minmax_multi_ops の BRINインデックスで date型の値をより適切に処理するようになりました。  (Tomas Vondra) (16)(15)(14)</li>
<p>
日付の距離計算が逆方向であったため、マージするエントリを適切に決定できませんでした。このようなインデックスは正しい結果を返すものの、本来よりも大幅に非効率でした。該当する BRIN インデックスは再作成することを推奨します。
</p>
<li>datetime_minmax_multi_ops の BRINインデックスで、timestamp および timestamptz 型の無限値や大きな値をより適切に処理するようになりました。  (Tomas Vondra) (16)(15)(14)</li>
<p>
無限（infinity、-infinity）が、他の値から大きな距離ではなく、距離ゼロと誤って処理されていて、マージするエントリを適切に決定できませんでした。また、無限ではないけれども巨大な値（タイムスタンプとして表現できる上限に近い値）では、内部オーバーフローを起こして、やはり、マージするエントリを適切に決定できませんでした。このようなインデックスは正しい結果を返すものの、本来よりも大幅に非効率でした。該当する BRIN インデックスは再作成することを推奨します。
</p>
<li>interval_minmax_multi_ops の BRINインデックスで極端な interval型の値での演算オーバーフローを回避するようになりました。  (Tomas Vondra) (16)(15)(14)</li>
<p>
このバグは大きな interval型の値を該当するインデックスに挿入するときに、予期せぬエラー「ERROR:  interval out of range」をもたらします。
</p>
<li>複合パーティションキーを持つハッシュパーティションテーブルに対するステップ生成と実行時プルーニングが修正されました。  (David Rowley) (16)(15)(14)(13)(12)(11)</li>
<p>
プルーニングとはパーティションテーブルへの問い合わせで一部パーティションの走査を省略することを意味し、ここでのステップとはそのための情報が格納されたデータ構造を意味します。
</p>
<p>
複数あるパーティションキーの 1つに IS NULL条件がある一部の場合にクラッシュする可能性がありました。
</p>
<li>MERGE での同時行更新の再チェックの不整合が修正されました。  (Dean Rasheed) (16)(15)</li>
<p>
READ COMMITTED モードでは UPDATEは、対象行が同時実行トランザクションから更新されたことを検知したなら、対象行に関する問い合わせの WHERE句を再チェックします。MERGE において、この再チェック処理が適切に動作しておらず、新たに更新された行を再度更新すべきかの判断を誤る可能性がありました。
</p>
<p>
本障害により、READ COMMITTEDモードでの同時実行で、MERGE が誤った問い合わせ結果（誤った更新結果）となる可能性がありました。
</p>
<li>継承テーブルに対する UPDATE、DELETE、MERGE で、親テーブルが制約で除外されるときでも、対象テーブルを正しく識別するようになりました。  (Amit Langote, Tom Lane) (16)(15)(14)</li>
<p>
コマンドで指定したテーブルが制約により処理対象から除外されているけれども、その子孫テーブルは除外されていない場合、最初の除外されていない子孫テーブルを主対象テーブルとみなしていました。
</p>
<p>
この誤りにより、文レベルのトリガが子テーブルに対して発火する誤動作が生じました。加えて、バージョン16 では予期せぬエラーも発生しました。
</p>
<pre>
（16.0 でのエラー発生例）
db1=# CREATE TABLE t8p (f1 int, f2 int, f3 int, check (f1 < 10) NO INHERIT);
db1=# CREATE TABLE t8c () INHERITS (t8p);
db1=# INSERT INTO t8c SELECT i, i+1, 0 FROM generate_series(1,1000) i;
db1=# CREATE INDEX ON t8c (f1, f2);
db1=# UPDATE t8p SET f3 = 11 WHERE f1 = 12 and f2 = 13;
ERROR:  invalid perminfoindex 0 in RTE with relid 16648
</pre>
<li>btree の ScalarArrayOpExprノードのマーク/リストア処理で、境界値の誤りが修正されました。  (Peter Geoghegan) (16)(15)(14)(13)(12)(11)</li>
<p>
ScalarArrayOpExpr は「indexcol = ANY(ARRAY[...])」や「indexcol IN (...)」といった検索条件で使われるエグゼキュータノードです。マーク/リストア処理とは、処理位置を覚えておいて再開する btreeインデックス検索の内部処理です。
</p>
<p>
本障害により、誤った問い合わせ結果が生じて、結果に含まれるべき行が失われる可能性がありました。
</p>
<li>Memoizeプラン要素の実行における問い合わせ実行内でのメモリリークが修正されました。  (Orlov Aleksej, David Rowley) (16)(15)(14)</li>
<li>集合を返す関数が、繰り返しゼロ行を返す場合のクエリ内メモリリークが修正されました。  (Tom Lane) (16)(15)(14)(13)(12)(11)</li>
<p>
行数の多いテーブルに対する jsonb_array_elements() 関数実行で引数でjsonb型の列の存在しないキーを指定したときにメモリリークが発生する現象が報告されました。
</p>
<li>cursor_to_xmlschema() 関数がデータを返さないポータルに適用された場合でもクラッシュしないようになりました。  (Boyu Yang) (16)(15)(14)(13)(12)(11)</li>
<li>連続した pg_logical_slot_get_changes() 関数の呼び出しの間でオリジンフィルタ条件の不適切な共有が修正されました。  (Hou Zhijie) (16)</li>
<p>
この関数の 1つの呼び出しで設定されたオリジン条件が、オリジン引数を指定しなかった後の呼び出しで再使用されていました。これは意図された動作ではありません。
</p>
<li>contrib/pgrowlocks の pgrowlocks() 関数がパーティションテーブルに適用された場合に意図したエラーが表示されるようになりました。  (David Rowley) (16)(15)(14)(13)(12)</li>
<p>
以前は「ERROR:  only heap AM is supported」という的外れなエラーが発生していました。「ERROR:  ".." is a partitioned table」が本来出るべきエラーです。
</p>
<li>さまざまな SQL関数で無効なインデックスをよりきれいに処理するようになりました。  (Noah Misch) (16)(15)(14)(13)(12)(11)</li>
<p>
pgstatindex()、pgstatginindex()、pgstathashindex()、または pgstattuple() が無効なインデックスに適用された場合、エラーを報告するようになりました。brin_desummarize_range()、brin_summarize_new_values()、brin_summarize_range()、または gin_clean_pending_list() が無効なインデックスに適用された場合は、デバッグ・レベルのメッセージを報告する以外は何もしない動作になります。
</p>
<p>
以前は、これらの関数はインデックスを処理しようとして、失敗した CREATE INDEX の残骸の内容によっては奇妙なエラーを出すことがありました。「ERROR:  could not read block 0 in file」が出るケースが報告されました。
</p>
<li>to_tsvector() への長い入力に対する、早すぎるメモリ割り当てエラーを回避するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)(11)</li>
<p>
実際には処理可能な場合でも、「ERROR:  invalid memory alloc request size .....」が発生することがありました。
</p>
<li>tsvector型のバイナリ入力関数 tsvectorrecv() で構築された tsvectorデータの過剰なサイズ割り当てが修正されました。  (Denis Erokhin) (16)(15)(14)(13)(12)(11)</li>
<p>
受信ベクトルに位置データが含まれている場合、バイナリ受信関数は、完成した tsvector に無駄なスペース（位置データのサイズにほぼ等しい）を残していました。極端な場合、これにより出力時に長さ制限を下回っていたベクトルに対して「ERROR:  lexeme length exceeded maximum total lexeme length」が発生する可能性がありました。いずれの場合もディスクスペースが無駄になる可能性がありました。
</p>
<li>破損した PGLZ圧縮データの検査が改善されました。  (Flavien Guedez) (16)(15)(14)(13)</li>
<p>
以前はクラッシュ（セグメンテーション違反）が発生していました。
</p>
<li>run_as_ownerオプションのコマンドによる変更が実際に適用されるようにALTER SUBSCRIPTION が修正されました。  (Hou Zhijie) (16)</li>
<p>
これまでは ALTER SUBSCRIPTION ... SET (run_as_owner = ...) を実行しても効いていませんでした。
</p>
<li>パーティションテーブルへの一括テーブル挿入が修正されました。  (Andres Freund) (16)</li>
<p>
パーティション間での挿入状態の不適切な共有により、COPY FROM 中に失敗する可能性があり、典型的には「ERROR:  could not read block NNNN in file XXXX: read only 0 of 8192 bytes」が発生していました。
</p>
<li>COPY FROM で必要のない列のデフォルト値評価を避けるようになりました。  (Laurenz Albe) (16)</li>
<p>
これにより、デフォルト値が実際にはその列で有効でない場合や、デフォルトの式が現在の実行コンテキストで失敗する場合に発生するエラーが回避されます。このような特殊なケースは、ダンプのリストア時に発生することがありました。15.x 以前のリリースではこのような状況にならなかったため、16.x 以降について修正されました。
</p>
<li>COPY FROM でサポートされていないエンコーディング変換が必要な場合に正常に失敗するようになりました。  (Tom Lane) (16)(15)(14)</li>
<p>
最近のリファクタリングで、意図していたエラーチェックが誤って削除され、有用なエラーメッセージの代わりに「ERROR:  cache lookup failed for function 0」が出力されていました。
</p>
<li>EXPLAIN によって表示されるようにマークされたパラメータの起動時の値がNULL である場合に、EXPLAIN でのクラッシュを回避するようになりました。  (Xing Guo, Aleksander Alekseev, Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
PostgreSQL本体には、これに適合する組み込みパラメータはありませんが、拡張機能でそのようなパラメータを定義することができます。
</p>
<li>「ON COMMIT DROP」での一時テーブル削除中にスナップショットがあることを確認するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)(11)</li>
<p>
これにより、一時テーブルのカタログエントリが（非常に複雑な「CHECK」条件などで）TOAST を必要とするほど大きい幅のフィールドを持つ場合の誤動作が防止されます。
</p>
<p>
CREATE TEMP TABLE でアサート失敗が発生する動作が報告されました。
</p>
<li>system() によってフォークされたばかりの子プロセスの、シャットダウン信号に対する不適切な応答が回避されました。  (Nathan Bossart) (16)(15)(14)(13)(12)(11)</li>
<p>
Cライブラリ関数の system() は archive_command 設定などでPostgreSQL が外部コマンドを呼ぶ動作で使用されています。system() によってフォークされたものの、目的の子プログラムをまだ実行していない子プロセスが、親サーバープロセス向けのシグナルを受信して動作するおそれがありました。これにより、終了時にクリーンアップ処理が重複して実行されてしまいます。
</p>
<p>
fastシャットダウンに対してアサート失敗する動作が報告されました。
</p>
<li>フロントエンドプログラム（pg_ctl や pg_controldata、pg_checksums）で、pg_control の不正な読み取りに対応するようになりました。  (Thomas Munro) (16)(15)(14)(13)(12)</li>
<p>
ファイルシステムによっては、サーバがそのファイルに同時に書き込むときに、pg_control の読み込みがアトミックな動作にならないことがあります。これは不正な CRC によって検出できます。エラーを報告する前に、数回再試行してファイルが有効になるかどうかを確認するようになりました。
</p>
<li>関連する SQL関数で pg_control の不正な読み取りが回避されました。  (Thomas Munro) (16)(15)(14)(13)(12)(11)</li>
<p>
ファイルの一貫したビューを確実に取得できるように、pg_control を読み取る前に適切なロックを取得するようになりました。関数 pg_control_system()、pg_control_checkpoint()、pg_control_recovery()、pg_control_init() で修正が行われました。
</p>
<li>「ORDER BY」または「DISTINCT」を使用した集計関数の計画時に発生するエラー「ERROR:  could not find pathkey item to sort」が修正されました。  (David Rowley) (16)</li>
<li>バックエンドアクティビティの文字列配列のサイズを計算するときに、整数オーバーフローの発生が回避されました。  (Jakub Wartak) (16)(15)(14)(13)(12)</li>
<p>
64ビットマシンでは、track_activity_query_size 設定値は、許可される接続数を乗算したときに 32ビットのオーバーフローを引き起こすのに十分大きな数となります。
</p>
<p>
該当する処理が実行される代表的な操作は pg_stat_activityビューの参照です。max_connections が 3000 以上、track_activity_query_size = 1MB のとき、「SELECT * FROM pg_stat_get_activity(NULL)」に対して、「ERROR:  invalid memory alloc request size 18446744072590721024」が発生するケースが報告されました。
</p>
<li>継承テーブルの ANALYZE に対して、pg_stat_progress_analyzeビューで一貫性のない進捗状況統計が一時的に表示される問題が修正されました。  (Heikki Linnakangas) (16)(15)(14)(13)</li>
<p>
current_child_table_relidフィールドの更新と同時に、ブロックレベルのカウンタをゼロにリセットする必要がありました。
</p>
<li>統計カウンタに WAL書き込みを報告するようにbackground writer が修正されました。  (Nazir Bilal Yavuz) (16)(15)(14)</li>
<p>
background writerプロセスからの WAL書き込みがこれまでpg_stat_walビューで参照できる統計情報に反映されませんでした。
</p>
<li>pgstat_report_wal() で強制フラッシュ動作の混乱が修正されました。  (Ryoga Yoshida, Michael Paquier) (16)(15)</li>
<p>
本障害により、WAL と I/O に関する一部の統計情報が PostgreSQLサービス停止で失われてしまうおそれがありました。
</p>
<li>一時テーブルの拡張（ブロック追加）に関する統計追跡が修正されました。  (Karina Litskevich, Andres Freund) (16)</li>
<p>
以前は、一時テーブルの書き込みが通常テーブルの書き込みとしてカウントされていました。
</p>
<li>track_io_timing が有効なときにリレーション拡張操作にかかる時間を書き込み時間に含めるようになりました。  (Nazir Bilal Yavuz) (16)</li>
<li>キャッシュされたCALL文の依存関係を追跡し、必要に応じて再計画するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)(11)</li>
<p>
CALL文の引数でインライン化されている関数を置き換えする DDLコマンドでは、PL/pgSQL によるキャッシュを捨てる必要がありました。これが行われなかったため、誤動作や「ERROR:  cache lookup failed」などの奇妙なエラーが発生していました。
</p>
<pre>
（誤動作例）
db1=# CREATE FUNCTION f(int) RETURNS int LANGUAGE sql AS $$ SELECT $1 + 1 $$;
db1=# CREATE PROCEDURE p1(p int) LANGUAGE plpgsql
        AS $$ BEGIN CALL p2(f(p)); END $$;
db1=# CREATE PROCEDURE p2(p int) LANGUAGE plpgsql
        AS $$ BEGIN RAISE NOTICE '%', p; END $$;
db1=# CALL p1(10);
NOTICE:  11
db1=# DROP FUNCTION f(int);
db1=# CREATE FUNCTION f(int) RETURNS int LANGUAGE sql AS $$ SELECT $1 + 2 $$;
db1=# CALL p1(10);
ERROR:  cache lookup failed for function 16699
CONTEXT:  SQL statement "CALL p2(f(f1))"
PL/pgSQL function p1(integer) line 1 at CALL
</pre>
<li>OpenSSL接続のセットアップでエラーが出た後に発生する可能性があった、NULLポインタを解放することによるクラッシュを回避するようになりました。  (Sergey Shinderuk) (16)(15)</li>
<li>外側の問い合わせレベルから レコード型の値を解析するときに、正しくネストの深さを追跡するようになりました。  (Richard Guo) (16)(15)(14)(13)(12)(11)</li>
<p>
この見落としにより、アサート失敗やクラッシュ、または「ERROR:  bogos varno: ..」エラーが引き起こされる可能性がありました。レコード型を出力する共通テーブル式（WITH句）を使った問い合わせで現象の発生が報告されました。
</p>
<li>ScalarArrayOpExprプランノードにおけるハッシュ関数と否定関数の依存関係を追跡するようになりました。  (David Rowley) (16)(15)(14)</li>
<p>
これらの関数はノードの元の演算子が存在している間は消えないと考えられるためこれはほとんどの場合に無害です。
</p>
<li>レコード型のキャッシュ管理でエラー処理のバグが修正されました。  (Thomas Munro) (16)(15)(14)(13)(12)(11)</li>
<p>
誤った個所でちょうどメモリ不足エラーが起きると、無限ループをもたらす一貫しない状態が生じる可能性がありました。
</p>
<li>WALの読み取り中のメモリ不足エラーを FATAL として扱うようになりました。  (Michael Paquier) (16)(15)(14)(13)(12)</li>
<p>
以前はでたらめなデータ状態として扱っており、WAL の終わりに到達したものと解釈していましたが、それは間違っていて一貫しない WAL再生が引き起こされる可能性がありました。
</p>
<li>でたらめな WALレコード長フィールドに基づいてメモリーを割り振ろうとして起こりうるリカバリのエラーが修正されました。  (Thomas Munro, Michael Paquier) (16)(15)(14)(13)(12)</li>
<p>
プライマリ停止後にスタンバイが「FATAL:  invalid memory alloc request size ....」を出して止まる現象が報告されました。
</p>
<li>Windows で min_dynamic_shared_memory を 0 より大きくに設定したときに、パラレルクエリの SQL実行で「ERROR:  could not duplicate handle ...」エラーが生じる障害が修正されました。  (Thomas Munro) (16)(15)(14)</li>
<li>内部実装関数 GenericXLogFinish の処理順序が修正されました。  (Jeff Davis) (16)(15)(14)(13)(12)(11)</li>
<p>
このコードは、変更されたバッファをダーティとしてマークする前に WAL を書き込むことで、クラッシュ安全性に必要な条件に違反していました。この関数を使用する　PostgreSQL本体コードはありませんが、拡張機能（例えば contrib/bloom）は使用します。
</p>
<li>PL/Python例外処理の誤ったアサートが削除されました。  (Alexander Lakhin) (16)(15)(14)(13)(12)(11)</li>
<li>サブスクリプションの新しいオプション run_as_owner をダンプするよう pg_dump が修正されました。  (Philip Warner) (16)</li>
<p>
この見落としにより、サブスクリプションは run_as_owner を意図して true に設定していたとしても、常に false として復元されていました。これはバージョン16 より前のリリースの動作とは同等ではありません。
</p>
<li>選択的リストアが選択されたテーブルのテーブルレベルとカラムレベルのACL 両方を含むように pg_restoreが修正されました。  (Euler Taveira, Tom Lane) (16)(15)(14)(13)(12)(11)</li>
<p>
以前は両方のタイプとも存在する場合にテーブルレベルの ACL のみが復元されていました。
</p>
<li>pg_upgrade に abstime、reltime、tinterval のデータ型の使用について検査するロジックが追加されました。  (&Aacute;lvaro Herrera) (16)(15)(14)(13)(12)</li>
<p>
これらのデータ型は PostgreSQLバージョン12 で廃止されたため、アップグレード可能と主張する前に古いデータベースに存在しないことを確認します。
</p>
<li>Windows での pgbench で偽性のエラー「ERROR:  too many client connections」を回避するようになりました。  (Noah Misch) (16)(15)(14)(13)(12)</li>
<li>vacuumdb の -N オプションを複数与えた場合の処理が修正されました。  (Nathan Bossart, Kuwamura Masaki) (16)</li>
<p>
複数の -N オプションは、複数スキーマについてスキーマ内テーブルを除外すべきですが、クエリ生成の誤りで、実際には何も除外されていませんでした。
</p>
<li>vacuumdb が ANALYZEのみの動作モード（-Z、--analyze-only オプション）であっても、--buffer-usage-limit オプションに従うように修正されました。  (Ryoga Yoshida, David Rowley) (16)</li>
<li>contrib/amcheckで中断されたページ削除を破損として扱わなくなりました。  (Noah Misch) (16)(15)(14)(13)(12)(11)</li>
<p>
この修正で以下のような誤った報告が防止されます。
</p>
<pre>
ERRPR:  the first child of leftmost target page is not leftmost of its level ...
ERROR:  block NNNN is not leftmost ...
ERROR:  left link/right link pair in index XXXX not in agreement
</pre>
<p>
リカバリを終えたデータベースクラスタで、btree インデックスぺージを削除するWALレコードが中途であって、VACUUM がそれらをクリーンアップする前に、amcheck を実行するとこれらのエラーが発生していました。
</p>
<li>contrib/btree_ginで「&lt;」または「&lt;=」を使用して interval型のインデックスに対するインデックススキャンを行った際の障害が、修正されました。  (Dean Rasheed) (16)(15)(14)(13)(12)(11)</li>
<p>
このようなインデックススキャンは本来返すべきすべての値を返せず、誤った問い合わせ結果が生じました。
</p>
<li>LLVM 16 および 17のサポートが追加されました。  (Thomas Munro, Dmitry Dolgov) (16)(15)(14)(13)(12)</li>
<li>最近の macOSでのビルド時の警告を抑制しました。  (Tom Lane) (16)(15)(14)(13)(12)(11)</li>
<p>
Xcode 15 (macOS Sonoma とともにリリース) では、PostgreSQL のビルド中にライブラリの重複に関する警告が多数発生するようにリンカの動作が変更されました。これらは無害ですが目障りなため、同じライブラリを複数回引用することは避けるようになりました。
</p>
<p>
また、-multiply_define の使用も削除されました。これは明らかに無効なものでした。
</p>
<li>contrib/unaccent のルールファイルをビルドするとき、PostgreSQLビルドで --with-python が指定されておらず、PYTHON変数も設定されていない場合に、エラーにするのではなくパス指定無しの「python」コマンドを使うようになりました。  (Japin Li) (16)(15)(14)(13)</li>
<li>デフォルトのタイムゾーンの略語リストから「PHOT」（フェニックス諸島時間）が削除されました。  (Tom Lane) (16)(15)(14)(13)(12)(11)</li>
<p>
最近の Debian および Ubuntuリリースでは、基礎となる tzdbエントリがデフォルトでインストールされなくなったため、デフォルトリストにこの略語が存在すると、エラーが発生する可能性があります。必要であれば、カスタム略語ファイルを介して元に戻すことができます。
</p>
<li>共有カタログに対して正しい動作を行うように pg_stat_reset_single_table_counters() が修正されました。  (Masahiro Ikeda) (15)</li>
<p>
これまでは本関数でリセットしても共有カタログには効果がありませんでした。
</p>
<li>gtsvector_picksplit() の誤った実装が修正されました。  (Alexander Lakhin) (15)(14)(13)(12)(11)</li>
<p>
tsvector列の GiSTインデックスでのページ分割の決定が適切に行われない可能性がありました。
</p>
<p>
この障害により不正メモリ読み取りが生じるケースが報告されました。
</p>
<li>エラー後に同セッションでロジカルデコーディングが再試行されるときの、アサート失敗が修正されました。  (Hou Zhijie) (15)(14)(13)(12)(11)</li>
<li>autovacuum launcherプロセスの動作を止めてしまう可能性のある、データベース削除時の競合状態が修正されました。  (Andres Freund, Will Mortensen, Jacob Speidel) (15)</li>
<p>
競合で削除されたデータベースの統計エントリが残り、そのためにどのデータベースを処理するかの選択が混乱する可能性がありました。
</p>
<li>外部ソート処理における論理テープ制御でデータ型サイズの混乱が修正されました。  (Ranier Vilela) (15)(14)(13)</li>
<p>
Linux などの long が int よりも大きいプラットフォーム（Windows なら同サイズ）において、数テラバイトの一時ファイルを必要とする巨大なソート処理について、整数オーバーフローで誤動作を引き起こす可能性がありました。
</p>
<li>sysloggerプロセスの標準入力が意図せず閉じられることが回避されるようになりました。  (Heikki Linnakangas) (15)(14)(13)</li>
<li>SQLのパース解析中に意味のある処理を行わないユーティリティコマンドのプランキャッシュ再検証を行わないようになりました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
これにより CPUサイクルが節約されるだけでなく、スナップショットを設定してはならないトランザクション制御コマンドでのキャッシュ無効化後のエラーが防止されます。
</p>
<p>
プロシージャ内で COMMIT の次に SET TRANSACTION ISOLATION LEVEL を実行して、「ERROR:  SET TRANSACTION ISOLATION LEVEL must be called before any query」が発生する障害ケースが報告されました。
</p>
<li>テーブルの行データを処理するコードにおいて、値が使用されている間は参照渡しの attmissingval値を長期間有効なコンテキストに保持するようになりました。  (Andrew Dunstan) (15)(14)(13)(12)(11)</li>
<p>
これにより、タプルスロットの寿命がその値を構築したタプル記述子よりも長くなった場合に、不正なポインタが使用される可能性が回避されます。
</p>
<p>
予期せぬエラー「ERROR:  unsupported byval length: 32639」が生じて、その後にアサート失敗やクラッシュが生じるケースが報告されました。
</p>
<li>ALTER ROLE の後に search_path の有効な値を再計算するようになりました。  (Jeff Davis) (15)(14)(13)(12)(11)</li>
<p>
これにより、ロール名を変更後に特別な文字列「$user」の意味が再決定されます。
</p>
<li>pg_dump で pg_catalog スキーマのダンプを要求された場合のアサート失敗が修正されました。  (Peter Eisentraut) (15)</li>
<li>pg_basebackup で無効な一時スロット名が生成されないようになりました。  (Jelte Fennema) (15)(14)(13)(12)(11)</li>
<p>
サーバー接続が pgbouncer を介して実行されている場合でのみ発生が確認されています。
</p>
<li>未解放のセーブポイントがある場合に COMMIT AND CHAIN/ROLLBACK AND CHAIN が正しく動作するように修正されました。  (Liu Xiang, Tom Lane) (14)(13)(12)</li>
<p>
現在のトランザクションのプロパティを新しいトランザクションに伝播する代わりに、以前のトランザクションのプロパティをいくつか伝播していました。
</p>
<p>
以下のように実行したときに「SHOW transaction_isolation」に対して不適切な出力が得られるケースが報告されました。
</p>
<pre>
db1=# START TRANSACTION ISOLATION LEVEL SERIALIZABLE; COMMIT;
      START TRANSACTION ISOLATION LEVEL REPEATABLE READ;
      SAVEPOINT s; COMMIT AND CHAIN;
      SHOW transaction_isolation; 
      COMMIT;
</pre>
<li>スタンバイモードの WALリカバリで無効なページヘッダが見つかった場合にエラーが報告されるようになりました。  (Yugo Nagata, Kyotaro Horiguchi) (14)(13)(12)</li>
<p>
これまでは無効なページヘッダに対するエラー出力なしにページ読み込みのリトライが行われていました。
</p>
<li>複合型の定数フィールドへの参照を含むビューを逆解析するときに、「ERROR:  record type has not been registered」が発生していたのが回避されました。  (Tom Lane) (13)(12)(11)</li>
<p>
SEARCH/CYCLE を含む再帰問い合わせの EXPLAIN 出力でエラーが発生するケースが報告されました。
</p>
<li>RECORD型 の ROW() 式からフィールドを展開できるようになりました。  (Tom Lane) (12)(11)</li>
<p>
PostgreSQL 13 以降では、下記例のように f1、f2、… というフィールド名でレコード型から要素を参照することができます。本機能が PostgreSQL 11.x、12.x にもバックポートされました。
</p>
<pre>
db1=# SELECT (ROW(1,2,3)).f3;
 f3
----
  3
(1 row)
</pre>
</ol>

<div>
<a href="https://www.sraoss.co.jp/prod_serv/support/pgsql-mainte/?utm_source=sraoss-techblog&utm_medium=referral&utm_campaign=under-article-pgsql" rel="noopener" style="color:initial;" target="_blank" class="no-ext"></p>
<div style="background-color:#DAEFF6; padding:20px; border-radius:8px; text-align:center;">
SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。<br />
詳しくは<strong style="color:#2581c4;">弊社ホームページ</strong>をご覧ください。
</div>
<p></a>
</div>

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 11.21 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-21/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Wed, 16 Aug 2023 23:01:11 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.20]]></category>
		<category><![CDATA[PostgreSQL 11.21]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=12932</guid>

					<description><![CDATA[このリリースは 11.20 からの修正リリース（2023年 8月 11日リリース）です。 11.X からのアップデートではダンプ、リストアは不要です。 しかしながら、NULL値を含む列に BRINインデックスを使っている ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 11.20 からの修正リリース（2023年 8月 11日リリース）です。<br />
11.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、NULL値を含む列に BRINインデックスを使っている場合には、インデックスを再構築することを推奨します。<br />
また、11.14 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/11-14/ ">11.14 のリリース情報</a>も参照してください。</p>
<p><span id="more-12932"></span></p>
<h3>PostgreSQL 11.20 から 11.21 への変更点</h3>
<p>15.4、14.9、13.12、12.16、11.21 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>拡張のスクリプトで、クォートやバックスラッシュ、ドル記号を含む名前のスキーマや所有者名を置き換えすることが禁止されました。  (Noah Misch) (15)(14)(13)(12)(11)</li>
<p>
この制限は信頼された拡張に対する SQLインジェクションを防止するものです。
</p>
<p>
拡張のスクリプトには @extschema@ や @extowner@ といったプレースホルダを使うことができます。これに対して、作りこまれたスキーマ名や所有者名を適用させることで、SQLインジェクションが狙えました。標準で付属している拡張には脆弱性はありません。また、攻撃者はデータベース作成権限が必要です。(CVE-2023-39417)
</p>
<li>MERGE が行単位セキュリティ(RLS)ポリシーを適切に適用するように修正されました。  (Dean Rasheed) (15)</li>
<p>
MERGE が UPDATE アクションを実行するとき、ターゲットテーブルに定義された UPDATE と SELECT の RLSポリシーを適用して、通常の WHERE句 を持つ UPDATE の動作と一貫性を持たせるべきです。しかしながら、そうなっておらず、MERGEではINSERT の RLSポリシーを INSERT と UPDATE のアクションに適用していました。(CVE-2023-39418)
</p>
<p>
加えて、MERGE が DO NOTHING アクションを行うとき、ターゲットテーブルのDELETE の RLSポリシーを、既存行に適用していました。こちらはセキュリティ障害ではありませんが、予期せぬエラーを引き起こす可能性がありました。
</p>
<li>揮発性の関数を含む結合条件のラテラル結合で、Memoize を使わないように修正されました。  (Richard Guo) (14)(15)</li>
<p>
揮発性のフィルタ条件を含むサブプランに Memoize を適用すると、誤った問い合わせ結果がもたらされます。この検査が一部漏れていて、LATERAL を使う場合にこのような実行プランが発生する可能性がありました。
</p>
<li>BRINインデックスで、行の無い範囲と全てが NULL の範囲を混同して、誤った問い合わせ結果を返す誤りが修正されました。  (Tomas Vondra) (15)(14)(13)(12)(11)</li>
<p>
本障害により、返すべき NULL値の結果を返さない可能性があります。NULL を検索するかもしれない BRINインデックスは、バージョンアップ後に再構築してください。
</p>
<pre>
（誤動作例: SELECT結果で 1000行が返るべきところで 0行が返っている）
db1=# CREATE TABLE t_brin (id int, v text);
db1=# CREATE INDEX ON t_brin USING brin (id);
db1=# INSERT INTO t_brin SELECT null, null FROM generate_series(1, 1000);
db1=# INSERT INTO t_brin SELECT g, g::text FROM generate_series(1001, 2000) g;
db1=# SET enable_seqscan TO false;
db1=# SELECT id FROM t_brin WHERE id IS NULL;
 id
----
(0 rows)
</pre>
<li>DROP DATABASE が中断されたときに破損したデータベースが残ってしまうのを回避するようになりました。  (Andres Freund) (15)(14)(13)(12)(11)</li>
<p>
これまで DROP DATABASE が取消できない段階に進んだ後に中断された場合、対応する pg_database の行の削除はロールバックされてしまうため、DROP を中断したデータベースは（中身はおそらく破損しているにもかかわらず）アクセス可能な状態で残りました。
</p>
<p>
取消不能な操作を開始する前に、データベースに使用不能(invalid) の印付けをするように修正されました。この印付けをした後の何らか失敗で、データベースは部分的に残った状態になりますが、再度 DROP DATABASE をする以外のことはできなくなります。例えば接続を試みると「ERROR:  cannot connect to invalid database "..."」というエラーになります。
</p>
<li>パーティションインデックスで、有効であるか未作成であるかが正しく印付けされるようになりました。  (Michael Paquier) (15)(14)(13)(12)(11)</li>
<p>
新たなパーティションインデックスが既存インデックスと一致するけれども、一部パーティションにおいては無効なインデックスである場合に、パーティションインデックスは有効と印付けしてしまう可能性がありました。これにより、その後のパーティションテーブルに対する問い合わせで、誤動作（誤った問い合わせ結果）やアサート失敗を引き起こす可能性がありました。
</p>
<li>ALTER TABLE .. ATTACH PARTITION で、パーティションインデックスと子インデックスを照合するとき、無効な子インデックスを無視するようになりました。  (Michael Paquier) (15)(14)(13)(12)(11)</li>
<p>
アタッチするテーブルの無効なインデックスは無視されて、その代わりに新たな子インデックスが作成されるようになりました。
</p>
<li>全てのパーティションがアタッチされた後、パーティションインデックスを有効と印付けするとき、エラーになることがあり、修正されました。  (Michael Paquier) (15)(14)(13)(12)(11)</li>
<p>
インデックスの pg_index エントリの更新では、有効フラグ(indisvalid)列以外の列について古いデータを使う可能性がありました。報告された症状の例は、トランザクション内でいくつかの DDL 操作をした後にパーティションのアタッチを行うと「ERROR:  attempted to update invisible tuple」が出ることです。
</p>
<li>拡張に拡張の指定スキーマ外のオブジェクトが含まれている場合に、ALTER EXTENSION SET SCHEMA が、エラーをだすようになりました。  (Michael Paquier, Heikki Linnakangas) (15)(14)(13)(12)(11)</li>
<p>
このような場合には以前から以下のエラーが出る実装になっていましたが、検出できないケースがあり、予期せぬ振る舞いが生じていました。
</p>
<pre>
ERROR:  extension "ext1" does not support SET SCHEMA
DETAIL:  obj1 is not in the extension's schema "extscm1"
</pre>
<li>テーブルアクセスメソッドの依存関係の追跡について修正されました。  (Michael Paquier) (15)</li>
<p>
ALTER TABLE ... SET ACCESS METHOD は、テーブルのアクセスメソッドを変更するときに、関連する pg_depend のエントリを更新することに失敗していました。
</p>
<p>
この障害により、組み込みでないアクセスメソッドを使っているとき、依存するオブジェクトが未だあるのにアクセスメソッドを DROP できてしまう危険性がありました。
</p>
<p>
なお、バージョンアップで本修正を適用しても、既に欠損している pg_depend のエントリが修復されることはありません。
</p>
<li>プランナで一意性の証明に部分的なユニークインデックスを使わないようになりました。  (David Rowley) (15)(14)(13)(12)(11)</li>
<p>
テーブルをスキャンするときにその部分インデックスを使わない場合には読み取った行の一意性が保たれないかもしれないため、これにより誤ったプランを作ってしまう可能性がありました。結果として誤った問い合わせ結果も生じます。
</p>
<li>偽性の定数の JOIN句を伴う外部テーブルの結合で、不正なプラン生成を回避するようになりました。  (Etsuro Fujita) (15)(14)(13)(12)(11)</li>
<p>不正なプランにより、結果として誤った問い合わせ結果が生じる可能性もあります。</p>
<p>
以下の例では、リモートサーバ側で結合を行うプランとなっていますが、「CURRENT_USER = SESSION_USER」の条件が消えてしまっています。このような結合をリモートサーバ側にプッシュダウンすることは、今のところサポートされていません。このような結合対象テーブルと無関係な条件が付加されている場合には、ローカルサーバ側で結合するプランを生成するように修正されました。
</p>
<pre>
（不正なプラン生成の例）
db1=# explain (verbose, costs off) 
        SELECT t1.c1, t2.c1 FROM ft1 t1
	      JOIN ft2 t2 ON (t1.c1 = t2.c1 AND CURRENT_USER = SESSION_USER)
          ORDER BY t1.c3, t1.c1 OFFSET 100 LIMIT 10;
                                                                              QUERY PLAN                                                                        
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit
   Output: t1.c1, t2.c1, t1.c3
   ->  Foreign Scan
         Output: t1.c1, t2.c1, t1.c3
         Relations: (public.ft1 t1) INNER JOIN (public.ft2 t2)
         Remote SQL: SELECT r1.c1, r2.c1, r1.c3 FROM (public.t1 r1 INNER JOIN public.t2 r2 ON (((r1.c1 = r2.c1)))) ORDER BY r1.c3 ASC NULLS LAST, r1.c1 ASC NULLS LAST
(6 rows)
</pre>
<li>RLS（行単位セキュリティ）の式とセキュリティバリアビューにおいて、ルールアクションを展開するときに、副問い合わせを正しく扱うようになりました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
プラン作成時にアサート失敗や奇妙なエラーを引き起こす可能性がありました。
</p>
<li>SERIALIZABLE分離モードにおける衝突検出での競合条件が修正されました。  (Thomas Munro) (15)(14)(13)(12)(11)</li>
<p>
ビットマップヒープスキャンを使っていて、GINインデックスを使っていて、さらに、最初は空の btree インデックスを調べるときに、衝突が見落とされる可能性がありました。
</p>
<p>
このような場合、不適切に衝突しているトランザクションのコミットを許すことになるため、トランザクション分離に失敗する結果を招きます。これにより、誤った問い合わせ結果や誤った更新結果が生じる可能性がありました。
</p>
<li>継承テーブルまたはパーティションテーブルを対象とした、EvalPlanQual検査の誤動作が修正されました。  (Tom Lane) (15)(14)</li>
<p>
EvalPlanQual検査は、READ COMMITTED分離モードのトランザクションで実行される処理です。この誤りにより、READ COMMITTED分離モードで UPDATE や DELETE動作が、同時更新と衝突しているためスキップされるべきところでも、実行されました。これにより、誤った問い合わせ結果や誤った更新結果が生じる可能性がありました。
</p>
<pre>
（報告された誤動作ケース）
db1=# CREATE TABLE t12p (id int, v int);
db1=# CREATE TABLE t12c1 () INHERITS (t12p);
db1=# CREATE TABLE t12c2 () INHERITS (t12p);
db1=# INSERT INTO t12c1 VALUES (1,1);
db1=# INSERT INTO t12c2 VALUES (1,1);

（トランザクション１）
db1=# BEGIN;
BEGIN
db1=*# UPDATE t12p SET v = 2 WHERE v = 1;
UPDATE 2
              （トランザクション２）
              db1=# BEGIN;
	          BEGIN
              db1=*# DELETE FROM t12p WHERE v = 1;
			  （ここでロック待ちになる）

db1=*# COMMIT;
COMMIT
               (ロック待ちが解放されるが 1行だけ DELETEされる誤動作）
               DELETE 1        
               db1=*# SELECT * FROM t12p;
                 id |  v
                ----+-----
                  1 |  2
               (1 row)

               db1=*# COMMIT;
               COMMIT
</pre>
<li>外側の入れ子ループ（Nested Loop）に由来するパラメータを含むキーのハッシュを伴うハッシュ結合について、修正されました。  (Tom Lane) (15)(14)(13)(12)</li>
<p>
そのようなパラメータの値が変更された後で結合を再スキャンするとき、ハッシュテーブルを再構築しなければなりませんが、それをしていませんでした。その結果、結合の出力行が失われて誤った問い合わせ結果が生じることがありました。
</p>
<pre>
(バージョン15.3 での障害動作例)
db1=# CREATE TABLE t13a AS SELECT generate_series(1, 10)::int AS c1;
db1=# CREATE TABLE t13b AS SELECT c1 AS c2 FROM t13a;
db1=# CREATE TABLE t13c AS SELECT c1 AS c3 FROM t13a;
db1=# SET enable_hashjoin TO off;
db1=# SELECT ta.c1, s.* from t13a ta, LATERAL (
        SELECT tb.c2, tc.c3 from t13b tb
          JOIN t13c tc ON tb.c2 = tc.c3 + ta.c1 ORDER BY 1,2) s;
　⇒ 45行の結果が返る（Hash Join 以外の方式で、正しい結果）

db1=# SET enable_hashjoin TO on;
db1=# SET enable_mergejoin TO off;
db1=# SELECT ta.c1, s.* from t13a ta, LATERAL (
        SELECT tb.c2, tc.c3 from t13b tb
          JOIN t13c tc ON tb.c2 = tc.c3 + ta.c1 ORDER BY 1,2) s;
　⇒ 9行の結果が返る（Hash Join が使われて、誤った結果）
</pre>
<li>複合型列のフィールドを更新しようとするときの間欠的に生じる障害が修正されました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
複合型列の値全体が TOAST外部格納を必要とするほど大きい場合、内部的なキャッシュ処理のタイミングによってはエラー（「ERROR:  unsupported byval length: ...」）やサーバプロセスのクラッシュが発生しました。
</p>
<li>トリガを伴う UPDATE 文のいくつかの場合で、問い合わせ処理内におけるメモリリークが防止されました。  (Tomas Vondra) (15)(14)(13)(12)</li>
<li>Incremental Sort 実行プランノードが再スキャンされるときの、問い合わせ処理内におけるメモリリークが防止されました。  (James Coleman, Laurenz Albe, Tom Lane) (15)(14)(13)</li>
<li>jsonpath の datetime() メソッドの入力として、小数点以下の秒を受け付けできるようになりました。  (Tom Lane) (15)(14)(13)</li>
<pre>
（修正前バージョンの動作、修正後は 2つ目の SELECT も成功する）
db1=# SELECT jsonb_path_query('"2023-08-10 12:34:56+9"', '$.datetime()');
      jsonb_path_query
-----------------------------
 "2023-08-10T12:34:56+09:00"
(1 row)

db1=# SELECT jsonb_path_query('"2023-08-10 12:34:56.789+9"', '$.datetime()');
ERROR:  datetime format is not recognized: "2023-08-10 12:34:56.789+9"
</pre>
<li>極めて複雑なテキスト検索で、スタックオーバーフローによるクラッシュが防止されました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
修正後は max_stack_depth 設定に基づいて、スタックの上限超過を報告する ERROR で問い合わせが終了するようになります。
</p>
<li>pg_hba.conf と pg_ident.conf で 10240バイトまでのトークンが使えるようになりました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
これまでは 256バイトが上限で、場合によっては長さが不足することがありました。そのような場合、「LOG:  authentication file token too long, skipping: ...」が出て、設定ファイルの読み込みに失敗します。LDAP認証で長いオプション設定値を与えるときに失敗するケースが報告されました。
</p>
<li>拡張が GUCプレフィックスの予約を宣言しているときに、該当する既存の設定項目が確実に検査されるようになりました。  (Karina Litskevich, Ekaterina Sokolova) (15)</li>
<p>
誤って一部のエントリが読み飛ばされて、見逃されることがありました。
</p>
<li>C++ の out of memory の条件に誤解があり、修正されました。  (Heikki Linnakangas) (15)(14)(13)(12)(11)</li>
<p>
JIT が使われている場合に、C++ の「new」で out of memory になるとき、想定された C++ の例外に進むべきところ、PostgreSQL の FATAL エラーになっていました。
</p>
<li>plancache.c での稀なヌルポインタのクラッシュが修正されました。  (Tom Lane) (15)(14)(13)</li>
<li>ロジカルレプリケーションのサブスクリプションが DROP されたときに、そのサブスクリプションに対する統計エントリのリークが回避されました。  (Masahiko Sawada) (15)</li>
<li>ページ解放が結果としてフリースペース範囲を合体させる場合に、おそらく有用な共有メモリセグメントの追跡を失うことがあり、修正されました。  (Dongming Liu) (15)(14)(13)(12)(11)</li>
<p>
セグメントは新しいフリースペースの大きさに対して適切な bin (集計区間) に移動されて、後続の検索で見つかるようになりました。この問題により、解放されたメモリが十分あるはずであるのに、動的共有メモリの割り当てに失敗することが報告されました。
</p>
<li>VACUUM がある種の btreeインデックスの破損を検出した後も継続できるようになりました。  (Peter Geoghegan) (15)(14)(13)(12)(11)</li>
<p>
無効な隣接ページリンクを検出すると、問題をログ出力しますが VACUUM処理は継続するようになります。これまでは ERROR を出して中断していました。REINDEX をしなければ壊れたインデックスは修復されませんが、そうするまで VACUUM を完了できないことは、より悪い問題を引き起こすリスクになります。
</p>
<li>VACUUM が pg_database.datfrozenxid や pg_database.datminmxid で無効なデータを検出した後、WrapLimitsVacuumLock が確実に解放されるようになりました。  (Andres Freund) (15)(14)(13)(12)(11)</li>
<p>
このロックはセッション終了や何らか他のエラーに遭遇した時には解放されますが、ロック解放に失敗することで後にデッドロックを引き起こす可能性がありました。
</p>
<li>クラッシュリカバリ時にプリペアドトランザクションの二重リプレイが回避されました。  (suyu.cmj, Michael Paquier) (15)(14)(13)(12)(11)</li>
<p>
いくつかの既にディスクにフラッシュされた 2相トランザクション状態データを伴うチェックポイント途中でのクラッシュの後、クラッシュリカバリがプリペアドトランザクションを 2回リプレイしようとして、startup プロセスで「FATAL:  lock is already held」などの致命的なエラーが発生する可能性がありました。
</p>
<li>新しく作成されたけれどもまだ空のテーブルが、次のチェックポイントでfsync されるようになりました。  (Heikki Linnakangas) (15)(14)(13)(12)(11)</li>
<p>
これを行わないと、オペレーティングシステムのクラッシュによって空のファイルが失われた場合、その後のテーブル操作が「could not open file」エラーで失敗する可能性がありました。
</p>
<li>UNLOGGED なインデックスの初期フォーク作成を必ず WAL に記録するようになりました。  (Heikki Linnakangas) (15)(14)(13)(12)(11)</li>
<p>UNLOGGEDインデックスのメインデータフォークは WAL に記録されませんが、クラッシュ後にインデックスをリストアするための一貫した状態を確保するために、その初期フォークは WAL に記録する必要があります。初期フォークが空の場合に WAL書き出しが行われていなかったため、修正されました。これは標準的インデックスアクセスメソッド(AM) では生じないケースですが、一部の拡張ではおそらく該当します。
</p>
<li>偽性の「missing contrecord」エラーが出力されないようになりました。  (Thomas Munro) (15)</li>
<p>
pg_waldump と walsender からの不正確な苦情がログに記録されるのを避けるために、この場合を単純な WAL の終了として扱います。WALレコードに問題がない場合でも、pg_waldump 実行時に下記のエラーメッセージが出力されていました。
</p>
<pre>
pg_waldump: error: error in WAL record at 0/1FFFF98: missing
                   contrecord at 0/1FFFFE0
</pre>
<li>jsonpath コードの過度に厳密なアサーションが修正されました。  (David Rowley) (15)(14)(13)(12)</li>
<p>
クエリが「like_regex」の結果に「.type()」演算子を適用した場合にアサート失敗していました。非アサートビルドではバグはありません。
</p>
<pre>
（アサートビルドでバックエンドプロセスが終了する SQL文の例）
SELECT jsonb_path_query('["string", "string"]',
                        '($[0] like_regex ".{7}").type()');
</pre>
<li>既にアボートされたトランザクションで、拡張クエリプロトコルを使用して空ステートメントを処理する際のアサート失敗を回避するようになりました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<li>stats_fetch_consistency 設定がトランザクション内で変更された場合のアサート失敗を回避するようになりました。  (Kyotaro Horiguchi) (15)</li>
<li>contrib/fuzzystrmatch の Soundex の difference() 関数が空の入力を正常に処理できるように修正されました。  (Alexander Lakhin, Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
アルファベット文字を含まない入力文字列を使用すると、予測不能な出力が発生しました。
</p>
<li>contrib/hstore で入力の空白チェックが強化されました。  (Evan Jones) (15)(14)(13)(12)(11)</li>
<p>
場合によっては、文字が誤って空白文字として認識されて捨てられてしまうことがありました。
</p>
<p>
Mac OS X の en_US.UTF-8 ロケールは isspace(0x85) をバグで真と返すため、UTF-8 では \u0105 が 0xc4 0x85 とエンコードされ、0x85 が空白文字と解釈されていました。
</p>
<li>contrib/intarray の gist__int_ops インデックス演算子クラスを使用した最大サイズを超過した入力配列が禁止されました。  (Ankit Kumar Pandey, Alexander Lakhin) (15)(14)(13)(12)(11)</li>
<p>
以前は、このような場合に NOTICE メッセージで報告しますが、そのまま続行して無効なインデックスエントリを作成していました。これはインデックスの読み取り時にクラッシュを引き起こす危険があります。「ERROR:  input array is too big (.. maximum allowed, .. current), ...」というエラーメッセージを出して、データ更新するコマンドを中断するようになりました。
</p>
<pre>
（これまで報告されていた NOTICEメッセージ例）
NOTICE:  input array is too big (199 maximum allowed, 3001 current), use gist__intbig_ops opclass instead
</pre>
<li>contrib/intarray の GiSTインデックスエントリで無駄な二重展開を回避するようになりました。  (Konstantin Knizhnik, Matthias van de Meent, Tom Lane) (15)(14)(13)(12)(11)</li>
<li>contrib/pageinspect の gist_page_items()関数が、インデックスに INCLUDE句で追加された列が含まれている場合でも動作するように修正されました。  (Alexander Lakhin, Michael Paquier) (15)(14)</li>
<p>
インデックスが INCLUDE指定によりインデックスキー以外の列を含んでいた場合、gist_page_items() はインデックスのリーフページで情報を表示できなかったり、非リーフページで無条件にクラッシュしていました。
</p>
<li>psql で標準入出力が端末でない場合に、PSQL_WATCH_PAGER環境変数を無視し、ページャを使わないようになりました。  (Tom Lane) (15)</li>
<p>
\watch 以外のコマンドでの PSQL_PAGER と同じ扱いになります。
</p>
<li>pg_dump で、関数定義時に一意インデックスへの依存関係を必要とする、BEGIN ATOMIC を用いた SQL関数を正しく処理できるように修正されました。  (Tom Lane) (15)(14)</li>
<p>
GROUP BY や ON CONFLICT句を使っている場合に該当する可能性がありました。そのような関数は一意インデックスの後にダンプする必要がありますが、そうなっておらず、「warning: could not resolve dependency loop」という警告が出力されました。
</p>
<li>pg_dumpで、依存関係ループの問題に関する詳細情報の表示が改善されました。  (Tom Lane) (15)</li>
<p>
詳細情報は infoレベルで出力されていましたが、-v (--verbose ) 指定無しのデフォルトのログレベルでは出力されないため、warningレベルで出力するようになりました。
</p>
<li>pgbenchで、preparedモードで空のパイプラインに対して生じるクラッシュが回避されました。  (&Aacute;lvaro Herrera) (15)</li>
<p>
ここでの空のパイプラインとは pgbenchスクリプトで \startpipeline の直後に\endpipeline を記述した場合を指します。
</p>
<li>pg_index.indisreplident がリレーションキャッシュのエントリ内で常に最新となるようになりました。  (Shruthi Gowda) (15)(14)(13)(12)(11)</li>
<p>
場合によっては値が古い可能性がありました。リレーションキャッシュのコピーに依存するコードは本体にないため、PostgreSQL に限って言えば潜在的なバグに過ぎません。ただし、これに起因してバグが発生する拡張が存在する可能性があります。
</p>
<li>make_etagsスクリプトで、Exuberant ctags 以外の ctag が動作するように修正されました。  (Masahiko Sawada) (15)</li>
<li>アーカイブが有効で、二相トランザクションのリカバリが必要な場合に、スタンバイサーバの昇格時に発生する障害が修正されました。  (Julian Markwort) (14)(13)</li>
<p>
必要な二相トランザクションが最新の (部分的な) ログセグメントに記録されている場合、「ERROR:  requested WAL segment .. has already been removed」という誤ったメッセージが出力され、昇格に失敗していました。
</p>
<li>遅延チェックポイント終了フラグの再初期化漏れが修正されました。  (suyu.cmj) (14)(13)(12)(11)</li>
<p>
チェックポイントが不必要に遅延したり、アサート有効ビルドでアサート失敗したりする可能性がありました。
</p>
<li>OpenSSL 3.0.0 以降でのコンパイル時に非推奨の警告を表示しないようになりました。  (Peter Eisentraut) (13)(12)(11)</li>
</ol>

<div>
<a href="https://www.sraoss.co.jp/prod_serv/support/pgsql-mainte/?utm_source=sraoss-techblog&utm_medium=referral&utm_campaign=under-article-pgsql" rel="noopener" style="color:initial;" target="_blank" class="no-ext"></p>
<div style="background-color:#DAEFF6; padding:20px; border-radius:8px; text-align:center;">
SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。<br />
詳しくは<strong style="color:#2581c4;">弊社ホームページ</strong>をご覧ください。
</div>
<p></a>
</div>

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 11.20 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-20/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Tue, 30 May 2023 00:00:58 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.19]]></category>
		<category><![CDATA[PostgreSQL 11.20]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=12725</guid>

					<description><![CDATA[このリリースは 11.19 からの修正リリース（2023年 5月 11日リリース）です。 11.X からのアップデートではダンプ、リストアは不要です。 しかしながら、11.14 よりも前のバージョンからアップデートする場 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 11.19 からの修正リリース（2023年 5月 11日リリース）です。<br />
11.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、11.14 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/11-14/ ">11.14 のリリース情報</a>も参照してください。</p>
<p><span id="more-12725"></span></p>
<h3>PostgreSQL 11.19 から 11.20 への変更点</h3>
<p>15.3、14.8、13.11、12.15、11.20 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>CREATE SCHEMA が search_path の変更をオーバーライドしないようになりました。  (Alexander Lakhin) (15)(14)(13)(12)(11)</li>
<p>
CREATE SCHEMA は 1つの文の中でスキーマ内要素も作成することができます。CREATE SCHEMA の中では、安全な search_path に変更される場合でも、新たに作るスキーマと元々有効であったスキーマが有効な状態で動作していました。これを利用して、スキーマを作れる権限を持つユーザは SECURITY DEFINER の関数や拡張のスクリプトの権限を奪取することができました。(CVE-2023-2454)
</p>
<li>集合（複数行）を返す関数のインライン化の後にも、行単位セキュリティポリシーが正しく働くように修正されました。  (Stephen Frost, Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
集合を返す SQL言語関数が、行単位セキュリティ(RLS)ポリシーを持つテーブルを参照していて、呼び出し元の問い合わせにインライン化できる場合に、その RLSポリシーは異なるロールでキャッシュされたプランの再使用を伴う一部の場合に正しく働きませんでした。
</p>
<p>
これにより、ユーザが本来見ることのできない行を参照したり更新したりすることができてしまいました。(CVE-2023-2455)
</p>
<li>STRATEGY WAL_LOG オプションを伴う CREATE DATABASE の後に、元となるテンプレートデータベースが破損する可能性があり、修正されました。  (Nathan Bossart, Ryo Matsumura) (15)</li>
<p>
不適切なバッファ処理が後のテンプレートの pg_classカタログの修正を喪失するリスクをもたらしていました。CREATE DATABASE 直後にテンプレートデータベース上で CREATE TABLE などのDDL を実行して、チェックポイントを行うと、DDL結果が失われたり、サービスのクラッシュ終了が発生することがありました。
</p>
<li>STRATEGY WAL_LOG オプションで CREATE DATABASE を実行したときのメモリリークと不要なディスク読み込みが修正されました。  (Andres Freund) (15)</li>
<li>CREATE SCHEMA で新たなスキーマ名を省略した場合のクラッシュを回避するようになりました。  (Michael Paquier) (15)(14)(13)(12)(11)</li>
<p>
SQL標準では「CREATE SCHEMA AUTHORIZATION role_name」と書くことができて、新たなスキーマ名は role_name になります。しかしながら、一部のコードパスはスキーマ名が指定されている想定になっていて、障害を引き起こしました。
</p>
<pre>
（クラッシュ発生例）
db=# CREATE ROLE role1;
db=# CREATE SCHEMA scm1;
db=# CREATE SCHEMA AUTHORIZATION role1 CREATE TABLE scm1.t1 (id int);
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
</pre>
<li>MERGEコマンドの様々なプランナの障害が修正されました。  (Tom Lane) (15)</li>
<p>
プラン作成時に「ERROR:  variable not found in ...」や「ERROR:  PlaceHolderVar found where not expected」などのエラーが出て、失敗することがありました。
</p>
<li>一部の場合における MERGE で報告される行数が修正されました。  (Dean Rasheed) (15)</li>
<p>
MERGE ではコマンドタグで報告する行数として、NULL を返す BEFORE ROWトリガにより実際には変更されない行数も数えていました。これは通常の UPDATE や DELETE の動作と整合しませんので、修正されました。また、MERGE が行をパーティション間で移動するときに、行を重複して数えないように修正されました。
</p>
<pre>
（誤動作例）
db=# CREATE TABLE t7 (id int PRIMARY KEY, v text);
db=# INSERT INTO t7 VALUES (1, 'A');
db=# CREATE FUNCTION f_trg7() RETURNS TRIGGER LANGUAGE plpgsql AS
       $$ BEGIN RETURN NULL; END; $$;
db=# CREATE TRIGGER trg7 BEFORE UPDATE ON t7 FOR EACH ROW
        EXECUTE FUNCTION f_trg7();

（いずれも実際には 0件更新だが UPDATEでは 0、MERGEでは 1 になっていた）
db=# UPDATE t7 SET v = 'X' WHERE id = 1;
UPDATE 0

db=# MERGE INTO t7 t USING (VALUES (1, 'Y')) s (id, v) ON t.id = s.id
       WHEN MATCHED THEN UPDATE SET v = s.v
	   WHEN NOT MATCHED THEN INSERT VALUES (s.id, s.v);
MERGE 1
</pre>
<li>同時更新を伴う MERGE の問題が修正されました。  (Dean Rasheed, &Aacute;lvaro Herrera) (15)</li>
<p>
MERGE により更新または削除される行が同時実行トランザクションで更新されるとき、一部の場合に不適切な振る舞いをしていました。MERGE の実行で、クラッシュや誤ったマージ動作、あるいは、何も行われない、という振る舞いが生じる可能性がありました。
</p>
<li>欠けていた MERGEコマンドの逆コンパイルに対応しました。  (&Aacute;lvaro Herrera) (15)</li>
<p>
MERGEコマンドを追加したときに見落とされていました。新形式の SQL関数で MERGE を使うときに必要で、ダンプや psql の \sf+ がエラーになりました。
</p>
<pre>
（エラー発生例）
db=# CREATE TABLE t9_src (id int primary key, dat text);
db=# CREATE TABLE t9_tgt (id int primary key, dat text);
db=# CREATE FUNCTION f9() RETURNS void LANGUAGE SQL
     BEGIN ATOMIC
     MERGE INTO t9_tgt USING t9_src s on s.id = t9_tgt.id
       WHEN MATCHED THEN UPDATE SET dat = s.dat
       WHEN NOT MATCHED THEN INSERT VALUES (s.id, s.dat);
     END;
db=# \q
$ pg_dump -s db
pg_dump: error: query failed: ERROR:  unrecognized query command type: 5
pg_dump: detail: Query was: EXECUTE dumpFunc('33892')
</pre>
<li>パーティションテーブルにおける外部キー制約のトリガの有効化/無効化について修正されました。  (Tom Lane) (15)</li>
<p>RE	そのような場合にパーティション上の複製されたトリガを名前から探していたため、ALTER TABLE ... ENABLE/DISABLE TRIGGER がエラーになっていました。OID を使う実装に修正されました。
</p>
<pre>
（エラー発生例）
db=# CREATE TABLE t10fk (id int PRIMARY KEY);
db=# CREATE TABLE t10 (id int PRIMARY KEY,
       fk_id int NOT NULL REFERENCES t10fk (id)) PARTITION BY RANGE (id);
db=# CREATE TABLE t10p1 PARTITION OF t10 FOR VALUES FROM (1) TO (100);
db=# ALTER TABLE t10 DISABLE TRIGGER ALL;
ERROR:  trigger "RI_ConstraintTrigger_c_33906" for table "t10p1" does not exist
</pre>
<li>インデックスで使われている複合型の変更が禁止されました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
ALTER TYPE はテーブル列で使われている複合型に対するバイナリ互換性の無い変更を、今のところ許していません。これまでインデックスで使われている場合について見落とされており、本修正で禁止されました。
</p>
<li>システム列を外部キーの要素とすることが禁止されました。  (Tom Lane) (15)(14)(13)(12)</li>
<p>
システム列として行ごと OID が廃止されたことにより、システム列に対する外部キー制約の用途は無くなったと考えられます。また、現状いくつかのコードはもはや対応していません。
</p>
<li>行単位セキュリティ(RLS) が設定されている親テーブルからの COPY TO が子テーブルの行をコピーしないようになりました。  (Antonin Houska) (15)(14)(13)(12)(11)</li>
<p>
ドキュメントには COPY TO は継承子テーブルの行をコピーしないと書かれています。しかしながら、RLS が有効な場合に誤って子テーブルの行がコピーされていました。
</p>
<li>array_position() および array_positions() 関数に空配列を渡した場合のクラッシュが修正されました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<li>to_char() 関数で範囲外データ取得の可能性があり、修正されました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
場合によってはクラッシュを引き起こす可能性がありました。
</p>
<li>translate() 関数におけるバッファオーバーラン読み出しが回避されました。  (Daniil Anisimov) (15)(14)(13)(12)(11)</li>
<p>
translate('54321', '12345', 'abcd') など、文字を削除させる動作をさせた場合に、範囲外バイトの読み込みが生じて、可能性は低いですがクラッシュを引き起こすおそれがありました。
</p>
<li>テキスト検索における文字クラス処理のロジックが、有効なロケールが C であるかを正しく検出できるように修正されました。  (Jeff Davis) (15)</li>
<p>
これまでデータベースのデフォルト照合順序に ICU を使っている場合に混乱がありました。
</p>
<li>interval型に対する空文字列の入力によるクラッシュが修正されました。  (Tom Lane) (15)</li>
<pre>
（クラッシュ発生例）
db=# SET IntervalStyle TO sql_standard;
db=# SELECT ''::interval;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
</pre>
<li>ISO-8601形式の interval値の表現で、フィールドの指数表現が再び使用可能になりました。  (Tom Lane) (15)</li>
<p>
interval型に対する「P0.1e10D」のような入力は ISO-8601 で公式には認可されていませんが、PostgreSQLではバージョン 15.0 まで長らく許容していました。15.0 で一度禁止されましたが、本バージョンから許容するようになりました。
</p>
<li>JSON文字列リテラルでのパースエラーに対するエラーカーソル設定が修正されました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
JSON値の中の文字列リテラルで構文エラーが検出されたほとんど場合に、エラーカーソルを適切に設定することに失敗していました。これは、少なくとも（違う箇所を示す）役に立たないエラーメッセージをもたらし、14.x、15.x では場合によってはクラッシュを引き起こすことがありました。
</p>
<pre>
（15.x でクラッシュを引き起こす例）
db=# SELECT E'\n"\\u00000"'::jsonb;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
</pre>
<li>現在の 64-bit XID よりも大きい vacuum_defer_cleanup_age設定によるデータ破損が修正されました。  (Andres Freund) (15)(14)(13)(12)</li>
<p>
そのような vacuum_defer_cleanup_age が設定されているとき、PostgreSQL 14.x、15.x では vacuum が誤って未だ有効な行バージョンを除去してしまう可能性がありました。PostgreSQL 13.x、12.x では GiST インデックスにのみ影響があり、インデックスページの早すぎる再利用が生じる可能性がありました。
</p>
<p>
結果として以下のような予期せぬエラーがあらわれることが報告されています。
</p>
<pre>
ERROR:  MultiXactId ... has not been created yet -- apparent wraparound
ERROR:  could not open file "base/12345/16789" (target block 999): ...
ERROR:  attempted to lock invisible tuple
ERROR:  could not access status of transaction 3456789
</pre>
<li>パーサが誤った入れ子の集約を検出するのに失敗する場合があり、修正されました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
集約関数は入れ子にできないため、「ERROR:  aggregate function calls cannot be nested」を出すのが正しい動作です。この見落としにより、パース時点で拒絶されるべき無効な問い合わせで、エグゼキュータでクラッシュやアサート失敗を引き起こす可能性がありました。
</p>
<pre>
（クラッシュ動作例）
db=# WITH cte22 (col1) AS (SELECT 1)
     SELECT avg((
         SELECT avg(a1.col1 ORDER BY (SELECT avg(a2.col2) FROM cte22))
       FROM cte22 a1)) FROM cte22 AS a2(col2);
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
</pre>
<li>GENERATED .. AS IDENTITY による serial型列の定義で SEQUENCE NAME オプションのパース時にパースツリーのデータ構造を破損しており、修正されました。  (David Rowley) (15)(14)(13)(12)(11)</li>
<p>
イベントトリガが壊れたパースツリーを取得する場合に問題が起きる可能性がありました。なお、SEQUENCE NAME はドキュメントに記載がありませんが、以下のように使用できます。
</p>
<pre>
CREATE TABLE t23 (id int GENERATED ALWAYS AS IDENTITY (SEQUENCE NAME seq23));
</pre>
<li>Initプランをあるノードから別ノードに移動するときに、プランノードの並列安全性マークを正しく更新するようになりました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
この誤りにより、実行時に「ERROR:  subplan "..." was not initialized」というエラーが生じる可能性がありました。Initプランはプランツリーやサブプランツリーの開始点です。
</p>
<li>拡張統計のコードで PlaceHolderVars での障害が回避されました。  (Tom Lane) (15)(14)</li>
<p>
統計の種別に dependencies を含む拡張統計を使用した問い合わせの実行時に予期せぬエラー「ERROR:  PlaceHolderVar found where not expected」が発生することがありました。
</p>
<li>サブクエリに適用される検索条件句をサブクエリ内のウィンドウ集約の実行時条件（Run Condition）に変換できるかについての、誤ったテストが修正されました。  (David Rowley) (15)</li>
<p>
このような形状の問い合わせでは、アサート失敗や、誤った問い合わせ結果、その他の異常が生じるが起きる可能性がありました。
</p>
<pre>
（予期せぬエラーが出るSQL例）
db=# SELECT * FROM (
       SELECT empno, salary, count((SELECT 1)) OVER (ORDER BY empno DESC) c
         FROM t26) emp WHERE c = 1;
ERROR:  WindowFunc not found in subplan target lists
</pre>
<li>集約関数の引数や FILTER句に副問い合わせが含まれるとき、ウィンドウ集約に対して逆変換による最適化が禁止されました。  (David Rowley) (15)(14)(13)(12)(11)</li>
<p>
この最適化では集約の引数式が繰り返し可能な結果を持つ必要があり、副問い合わせでは実現できないと考えられます。アサート失敗が報告されました。
</p>
<li>入れ子になった ARRAY[] コンストラクタの実行で、誤りが修正されました。  (Alexander Lakhin, Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
配列に対する必要サイズのオーバーフローを正しく検知できるように修正され、不正メモリアクセスによるクラッシュが回避されました。また、生成される配列の末尾のパディングをゼロ埋めするようになり、後の配列利用で奇妙な動作が生じる可能性が回避されました。
</p>
<li>複合型ドメイン配列内フィールドを更新するときのクラッシュが防止されました。  (Dmitry Dolgov) (15)(14)(13)(12)</li>
<p>
制約の無いドメインで発生します。
</p>
<pre>
（障害発生例）
db=# CREATE TYPE typ1 AS (c1 int, c2 int);
db=# CREATE DOMAIN dom1 AS typ1;
db=# CREATE TABLE t29 (a dom1[]);
db=# INSERT INTO t29 VALUES ('{"(10,20)","(30,40)"}');
db=# UPDATE t29 SET a[1].c1 = -1;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
</pre>
<li>boolean型の列に対するパーティション除去のロジックが修正されました。  (David Rowley) (15)(14)(13)(12)(11)</li>
<p>
「boolcol IS NOT TURE」のような条件での除去が正しく働かず、boolcol が NULL である行を返さない、誤った問い合わせ結果が生じる可能性がありました。この他に「(NOT boolcol)」でのパーティション化も誤って処理されていました。
</p>
<p>
パーティション除去とは enable_partition_pruning = on で有効となる、プラン作成でのパーティションテーブルに対する最適化です。
</p>
<li>パラレルハッシュ結合(Parallel Hash Join)でバッチ毎のクリーンアップでの競合状態を修正しました。  (Thomas Munro, Melanie Plageman) (15)(14)(13)(12)(11)</li>
<p>
parallel_leader_participation = off （デフォルトは on）の場合に、タイミングによってはクラッシュを起こす可能性がありました。
</p>
<li>EvalPlanQual の検査後、GENERATED列を再計算するようになりました。  (Tom Lane) (15)(14)(13)(12)</li>
<p>
READ COMMITTED 隔離レベルでは、問い合わせが最初に見つけたものよりも新しい行バージョンに、行更新の影響を再適用する必要があるかもしれません。その場合、同時の更新で変化した列に依存する GENERATED列を再計算する必要がありました。
</p>
<p>
EvalPlanQual は READ COMMITTED 隔離レベルの問い合わせで実行される内部処理です。本障害により、被参照列だけ更新されて、それに連動して計算される GENERATED列は元の値まま、という状態で行が読み取られる動作が報告されました。
</p>
<li>Memoizeプランの実行におけるメモリリークが修正されました。  (David Rowley) (15)(14)</li>
<li>パーティションテーブルに含まれる外部テーブルに対してバッチ挿入を使うときの、バッファの参照カウント漏れが修正されました。  (Alexander Pyhalov) (15)(14)</li>
<p>
警告ログメッセージ「WARNING:  buffer refcount leak: ...」が発生しました。
</p>
<li>ミリ秒以下の vacuum_cost_delay 設定が再び利用可能になりました。  (Thomas Munro) (15)(14)</li>
<p>
以前の修正の誤りのために 14.x、15.x ではミリ秒以下の値が捨てられて処理されていました。
</p>
<li>リレーション毎の vacuum_cost_delay設定が 0 のとき、遅延バランス処理をしないようになりました。  (Masahiko Sawada) (15)(14)(13)(12)(11)</li>
<p>
autovacuum がリレーション毎 vacuum_cost_delay設定付のテーブルを処理するときにはいつでも、遅延バランスは無効と考えられていましたが、設定値が 0 の場合にも誤って有効と判断されていました。
</p>
<li>列がビュー末尾に追加されたときの、稀な場合のクラッシュが修正されました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
更新可能ビューの元となるビューを CREATE OR REPLACE VIEW で列が増えるように作成しなおした場合に、その後の更新可能ビューへの読み書きで、予期せぬ警告（「WARNING:  problem in alloc set MessageContext: req size > alloc size ...」）や、トリガの奇妙な動作、クラッシュが生じることがありました。
</p>
<li>パーティションテーブルの更新における、MULTIEXPR_SUBLINKサブプラン実行での稀な障害が修正されました。  (Andres Freund, Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
パーティションテーブルに対して、「INSERT ... ON CONFLICT DO UPDATE SET (c1, ...) = (SELECT ...)」という構文を使用するとき、いずれかの子テーブルが親テーブルと同形でない場合（例えば列の物理順序が異なるなど）、クラッシュや誤ったデータ更新を引き起こす可能性がありました。一般的にはエグゼキュータの整合性チェックでエラーになるだけで済みます。
</p>
<p>
MULTIEXPR_SUBLINKサブプランは、実行プランツリーにおいて、複数の対象リスト要素を持つサブプランを意味します。
</p>
<li>DO ALSO INSERT ... SELECT ルールを持つビューに対する複数行の INSERT ... VALUES 内での DEFAULTマーカの処理が修正されました。  (Dean Rasheed) (15)(14)(13)(12)(11)</li>
<p>
 このような場合、一般的には「ERROR:  unrecognized node type: ...」エラーか、アサート失敗が生じます。
</p>
<pre>
（エラー発生例）
db=# CREATE TABLE t39 (a int, b int DEFAULT -1);
db=# CREATE VIEW v39 AS SELECT * FROM t39;
db=# CREATE RULE r39 AS ON INSERT TO v39 DO ALSO INSERT INTO t39 SELECT 1;
db=# INSERT INTO v39 VALUES (0, DEFAULT), (1, DEFAULT);
ERROR:  unrecognized node type: 148
</pre>
<li>ルールアクションでサブクエリ内の OLD と NEW を参照できるようになりました。  (Dean Rasheed, Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
このような参照は実際にはラテラル参照ですが、明示的に LATERAL と指定していない場合、クラッシュが生じる可能性がありました。
</p>
<p>
以下のような処理でアサート失敗が報告されました。
</p>
<pre>
db=# CREATE TABLE t40 (a int, b int DEFAULT -1);
db=# CREATE VIEW v40 AS SELECT * FROM t40;
db=# CREATE RULE r40i AS ON INSERT TO v40 DO ALSO
       INSERT INTO t40 SELECT * FROM (SELECT a FROM t40 WHERE NEW.a = t40.a) tt;
db=# INSERT INTO v40 VALUES (1), (2);
</pre>
<li>WITH句内に INSERT/UPDATE/DELETE を含む、ルールや SQL関数の逆コンパイル時に、ターゲットテーブルの別名を正しく出力するようになりました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
ダンプした結果、もとのコードと異なる内容が出力されてリストア不能になる動作が報告されました。
</p>
<pre>
（障害を起こす関数例）
db=# CREATE TABLE t41_1 (c1 int);
db=# CREATE TABLE t41_2 (c1 int);
db=# CREATE FUNCTION f41 (c1 int) RETURNS void LANGUAGE SQL
       BEGIN ATOMIC
       WITH delete_t41 AS ( DELETE FROM t41_1 WHERE c1 = $1 )
        INSERT INTO t41_1 (c1) SELECT $1 FROM t41_2;
       END;
</pre>
<li>SERIALIZABLE READ ONLY の最適化の欠陥が修正されました。  (Thomas Munro) (15)(14)(13)(12)(11)</li>
<p>
既に失敗したものと印付けされているトランザクションが、SERIALIZABLE で READ ONLY のトランザクションに対する安全なスナップショットの最適化について混乱させていました。一部の場合に最適化が不必要に省略されていました。また、別のある場合にはアサート失敗が起きていました（アサート無しのビルドでは何ら問題ありません）。
</p>
<li>ロジカルデコーディングプラグインの pgoutput で、キャッシュのコールバックスロットのリークを回避するようになりました。  (Shi Yu) (15)(14)(13)(12)(11)</li>
<p>
単一セッション内でプラグインの開始と停止を繰り返すと、「ERROR:  out of relcache_callback_list slots」が生じました。
</p>
<li>インデックス演算子クラスのオプションに対するカスタムバリデータの不要な呼び出しを回避するようになりました。  (Alexander Korotkov) (15)(14)(13)</li>
<p>
この変更は一部の予期せぬエラーが発生していた現象を修正します。
</p>
<li>複数列の BRINインデックスを複数のキーで走査するときに、無用な動作が回避されました。  (Tomas Vondra) (15)(14)</li>
<p>
現行コードは範囲にマッチするか判断するときに最後のスキャンキーだけを考慮していました。そのため、たいていインデックスを必要とするより多くスキャンしていました。
</p>
<pre>
（障害動作例）
db=# CREATE TABLE t45 (a int, b int); 
db=# INSERT INTO t45 SELECT g, g FROM generate_series(1, 1000000) g;
db=# CREATE INDEX ON t45 USING brin (a,  b);
db=# SELECT * FROM t45 WHERE a = 12345 AND b > 1; -- 遅く動作する
db=# SELECT * FROM t45 WHERE a > 1 AND b = 12345; -- 適切に高速動作する
</pre>
<li>BRIN の inet_minmax_multi_ops 演算子クラスでネットマスク処理が修正されました。  (Tomas Vondra) (15)(14)</li>
<p>
この誤りはアサート失敗を引き起こしますが、実運用むけビルドではほぼ無害です。
</p>
<li>GiSTインデックスのバッファ処理モード作成時に無効ポインタへのアクセスがあり、修正されました。  (Alexander Lakhin) (15)(14)(13)(12)(11)</li>
<p>
取得される値は重要では無いため、この誤りは実運用ビルドにおいて通常は無害と考えられます。原理的にはサーバクラッシュを引き起こす可能性があります。
</p>
<li>UPDATE や DELETE 動作のロジカルレプリケーションにおいて、除去した列と生成列を無視するようになりました。  (Onder Kalaci, Shi Yu) (15)(14)(13)(12)</li>
<p>
REPLICA IDENTITY FULL オプションのロジカルレプリケーションは、テーブルにこのような列が含まれていると、正しく行の特定ができず、変更がサブスクリプション側に反映されない挙動が発生しました。
</p>
<li>コミットタイムスタンプに対する SLRU バッファのストレージ I/O の待機イベント名が修正されました。  (Alexander Lakhin) (15)(14)(13)</li>
<p>
ドキュメントでは CommitTsBuffer という名前でしたが、CommitTSBuffer と実装されていました。関連の待機イベント名と一貫するように、ドキュメントの通りに修正されました。
</p>
<li>待機イベント SLRUFlushSync の報告が再び有効化されました。  (Thomas Munro) (15)(14)</li>
<p>
この待機タイプは 14.0 むけのコードリファクタリングの際に誤って削除されてしまっていました。
</p>
<li>保持する WALセグメントの数を計算するときに、アンダーフローの可能性があり回避されました。  (Kyotaro Horiguchi) (15)(14)(13)</li>
<p>
結果として wal_keep_size設定に正確には従わない可能性ありました。
</p>
<li>スタンバイモードにおけるスタートアップ進捗報告のオーバーヘッドが取り除かれました。  (Bharath Rupireddy) (15)</li>
<p>
スタンバイモードでは実際のところリカバリ進捗をしませんが、その場合でも追跡処理が行われていました。
</p>
<li>SCRAM-SHA-256 チャンネルバインディングで RSA-PSS 証明書がサポートされました。  (Jacob Champion, Heikki Linnakangas) (15)(14)(13)(12)(11)</li>
<p>
この機能には OpenSSL 1.1.1 以降でのビルドが必要です。この機能追加はサーバ・クライアントの両方に影響します。
</p>
<li>Windows におけるプロセスID 追跡での競合を回避しました。  (Thomas Munro) (15)(14)(13)(12)(11)</li>
<p>
PostgreSQLマスタプロセス(postmaster)が子プロセスが消えたことを観測する前に、OS がその子プロセスの PID を再利用する可能性がありました。これにより、同じ PID で複数の子プロセスが記録されることがあり、混乱を招きました。
</p>
<p>
本障害が原因と思われるアサート失敗が報告されました。
</p>
<li>実装内部の汎用リスト処理関数 list_copy_head() が空リストを正しく扱えるように修正されました。  (David Rowley) (15)</li>
<p>
PostgreSQL のコードでは問題に該当する使い方はありませんでしたが、拡張モジュールで問題が生じるかもしれません。
</p>
<li>SPI_result_code_string() で "SPI_OK_MERGE" と "SPI_OK_TD_REGISTER" を返す場合について欠けていたため、対応されました。  (Dean Rasheed) (15)(14)(13)(12)(11)</li>
<li>AllocSetRealloc() で誤った Valgrind むけの印付けが修正されました。  (Karina Litskevich) (15)(14)(13)(12)(11)</li>
<p>
大きい（8kBを越える）pallocチャンクのサイズが減るという一般的でない場合に、Valgrind検知を有効にしたビルドではチャックからのメモリ解放の定義された状態の印付けを誤っていて、Valgrindのテストで誤った結果が生じる可能性がありました。
</p>
<li>行単位セキュリティが有効なパーティションテーブルに対する MERGE でのアサート失敗が修正されました。  (Dean Rasheed) (15)</li>
<li>トランザクションになっているロジカルレプリケーションのメッセージをデコードするときのアサート失敗が回避されました。  (Tomas Vondra) (15)(14)(13)(12)(11)</li>
<li>正規表現のエスケープ処理でロケールの影響を回避しました。  (Jeff Davis) (15)(14)(13)(12)(11)</li>
<p>
非ASCII文字が後に続くバックスラッシュで、有効なロケールによってはアサート失敗が生じる可能性がありました。そのロケールの言語で数字を意味する非ASCII文字で問題が報告されました。
</p>
<li>log_newpage_range() で、指定範囲の最後の数ページが空の場合は、空の WALレコードを書き込もうとしないようになりました。  (Matthias van de Meent) (15)(14)(13)(12)(11)</li>
<p>
リリースされたバージョンでこのケースに到達可能かどうかは完全には明らかではありませんが、到達した場合はアサート失敗が発生する可能性があります。
</p>
<li>キャスト式を使用する PL/pgSQL の DOブロック での、セッション存続期間のメモリリークが修正されました。  (Ajit Awekar, Tom Lane) (15)(14)(13)(12)</li>
<li>Perl のリスト構造を多次元 SQL配列に変換する時の、配列の次元チェックが強化されました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
PL/perl は、データが値の長方形配列を成しておらずサブリストのネストが揃っていないときに、誤動作することがありました。このような場合、クラッシュやゴミ出力（誤った問い合わせ結果）が発生する可能性がありました。これからはエラーを出すようになります。
</p>
<li>Python のリスト構造を多次元 SQL配列に変換する時の、配列の次元チェックが強化されました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
PL/Python は、空のサブリストを処理するときや、データが値の長方形配列を成しておらずサブリストのネストが揃っていないとき、誤動作することがありました。前者は出力配列が空になり、後者はエラーが発生します。ただし、一部のケースではクラッシュしたり、予期せぬ出力（誤った問い合わせ結果）が発生していました。
</p>
<li>PL/Python の例外スタックの巻き戻しが修正されました。  (Xing Guo) (15)(14)(13)(12)(11)</li>
<p>
稀な障害例としては、PG_TRY 例外スタックをクリーンアップせずに戻ることがあり、次のスタックレベルが巻き戻される前に別のエラーが発生した場合にクラッシュする危険性がありました。
</p>
<li>libpq の PQconnectPoll() における一貫性のない GSS暗号化のエラー処理が修正されました。  (Michael Paquier) (15)(14)(13)(12)</li>
<p>
gssencmode が require に設定されていると、GSS の初期化に失敗した後でも、接続は dead とマークされませんでした。 TLS暗号化の同等のケースで以前から行われてきたように、直ちにエラーを返すように変更されました。
</p>
<li>-C ORACLE オプションでビルドされた ecpg プログラムで発生する可能性のあるデータ破損が修正されました。  (Kyotaro Horiguchi) (15)(14)(13)(12)(11)</li>
<p>
varcharsize をゼロに設定して ecpg_get_data() を呼び出すと、直前のフィールドの最後のバイトに終端ゼロ文字が書き込まれ、そのフィールドのデータが切り捨てられることがありました。
</p>
<li>列挙(enum)型の列でハッシュ分割されたパーティションテーブルを正常にリストアできるように pg_dump が修正されました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
列挙値のハッシュコードは列挙値に割り当てられた OID に依存するため、通常、ダンプとリストアの後は異なります。つまり、多くの場合、行は元のパーティションとは異なるパーティションに入る必要があります。ユーザは --load-via-partition-root オプションを指定することでこの問題を回避できますが、それが無ければ成功する可能性はほとんど無いため、pg_dump がこのようなテーブルで自動的にオプション適用するように変更されました。
</p>
<p>
また、--load-via-partition-root モードが使用されている場合、リストア前にターゲットテーブルを TRUNCATE を試行しないよう pg_restore が修正されました。これにより、デッドロックやデータの喪失の危険性が回避されます。
</p>
<li>Windows でシークできないファイルを正しく検出するようになりました。  (Juan Jose Santamaria Flecha, Michael Paquier, Daniel Watzinger) (15)(14)</li>
<p>
このバグにより、pg_dump がパイプに書き込む時、または pg_restore がパイプから読み込む時に誤動作が発生していました。ファイルに対して成功していた同じ処理がパイプ経由だと予期せぬエラーが出る動作が報告されました。
</p>
<li>pgbench の preparedモードでは、パイプラインを開始する前にパイプライン内のすべてのコマンドを準備(prepare)するようになりました。  (&Aacute;lvaro Herrera) (15)(14)</li>
<p>
これにより、pgbench スクリプトがパイプライン内でSERIALIZABLEトランザクションを開始しようとした時の以下エラーの発生を回避できます。
</p>
<pre>
ERROR:  SET TRANSACTION ISOLATION LEVEL must be called before any query
</pre>
<li>contrib/amcheck のヒープを検査するコードで、xmin または xmax がゼロのタプルを正しく処理するようになりました。  (Robert Haas) (15)(14)</li>
<p>
これまでそのような異常を見逃していました。
</p>
<li>contrib/amcheck では、エポックゼロより前にあると思われる xid を適切に扱うようになりました。  (Andres Freund) (15)(14)</li>
<p>
破損した場合、最初の xidエポックより前にあるように見える周回した 32ビットxid が表示されることがありました。このような値を 64ビット形式に昇格させると、はるか未来の値が生成され、結果として誤った報告が作成されることになります。このような場合には FirstNormalFullTransactionId を返すことで、合理的に正常に動作するようになりました。
</p>
<li>contrib/basebackup_to_shell で、パイプのオープン失敗を適切に検出するようになりました。  (Robert Haas) (15)</li>
<li>contrib/hstore_plpython で、変換される Python 値がマッピングでない場合のクラッシュが回避されるようになりました。  (Dmitry Dolgov, Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
これはエラーを出すべきですが、Python 3 ではチェックが誤動作するようにいくつかの API が変更されたため、クラッシュを起こしていました。
</p>
<li>ltree列の GiSTインデックスの siglen オプションを指定する場合は、4 の倍数であることが必要となりました。  (Alexander Korotkov) (15)(14)(13)</li>
<p>
それ以外の値を指定すると、インデックスコンテンツへのアクセスが不整合になります。インテル互換のハードウェアでは無害ですが、他のアーキテクチャではクラッシュを引き起こす可能性があります。
</p>
<li>contrib/pageinspect で、gist_page_items() 関数の不正な入力に対する防御が追加されました。  (Dmitry Koval) (15)(14)</li>
<p>
クラッシュする動作が報告されました。
</p>
<li>contrib/pg_trgm で満たす文字列が存在しない正規表現による誤動作が修正されました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
$foo のような正規表現は定義として正当ですが、この表現を満たす文字列は存在しません。正規表現コンパイラはそれを認識し、空の「非決定性オートマトン(NFA)」グラフを生成します。このようなグラフを pg_trgm の GIN または GiST インデックス修飾に最適化しようとすると、作業配列の末尾からアクセスすることになり、クラッシュが発生する可能性がありました。
</p>
<li>contrib/postgres_fdw の application_name パラメータにおけるエスケープシーケンスの処理が修正されました。  (Kyotaro Horiguchi, Michael Paquier) (15)</li>
<p>
エスケープを展開するコードは、例えば外部テーブルの自動ANALYZE の中など、バックグラウンドプロセスで実行されるとクラッシュする可能性がありました。
</p>
<li>contrib/pg_walinspect で pg_get_wal_records_info() のメモリ使用量が制限されました。  (Bharath Rupireddy) (15)</li>
<p>
これまで大容量メモリを使う動作をすることがありました。
</p>
<li>GNU互換の strip を使用して静的ライブラリを削除する場合は、--strip-unneeded オプションを使用するようになりました。  (Tom Lane) (15)(14)(13)(12)(11)</li>
<p>
以前は、 make install-strip で -x オプションが使用されていました。本変更により、llvm-strip の誤動作が回避され、出力もわずかに小さくなります。
</p>
<li>ドキュメント構築における DTDファイルの自動ダウンロードを、ドキュメントで推奨しなくなりました。また、Makefile で無効化されました。  (Aleksander Alekseev, Peter Eisentraut, Tom Lane) (15)(14)(13)(12)(11)</li>
<p>SGMLドキュメントを構築するには、現在では DocBook の DTDファイルをローカルにインストールすることが必須となっています。以前は xsltproc が sourceforge.net からこれらのファイルを実行中にダウンロードできましたが、sourceforge.net は現在 HTTPS アクセスのみを許可しており、これをサポートする xsltproc の一般的なバージョンはありません。これに対応して、そのようなことが可能または有用であることを示唆するドキュメント箇所が削除され、代わりに xsltproc の --nonet オプションがMakefile に追加されました。
</p>
<li>PGXSビルドで TAPテストを実行する場合、一時的な portlockディレクトリとしてより安全な場所を使用するように変更されました。  (Peter Eisentraut) (15)(14)(13)(12)(11)</li>
<p>
ビルドディレクトリの tmp_check の下に置くように変更されました。以前のコーディングでは、PGXSビルドは、必ずしも書き込み可能でないインストールディレクトリに配置しようとしていました。
</p>
<li>エジプト、グリーンランド、モロッコ、パレスチナの夏時間法改正に伴い、タイムゾーンデータファイルが tzdata release 2023c に更新されました。   (15)(14)(13)(12)(11)</li>
<p>
モスクワ時間に従っている場合、Europe/Kirov および Europe/Volgograd は、モスクワ時間に従う他のタイムゾーンとの整合性を保つため、数字による略語ではなく MSK/MSD という略語を使用するようになりました。また、America/Yellowknife は America/Edmonton と区別されなくなり、この地域の 1948年以前のタイムスタンプの一部に影響します。
</p>
<li>パーティションテーブルでのクローントリガの有効化/無効化が修正されました。  (Tom Lane) (14)(13)</li>
<p>
ALTER TABLE ... ENABLE/DISABLE TRIGGER USER はクローントリガをシステムトリガと誤解してスキップしていました。ENABLE/DISABLE TRIGGER の他の形式ではそれらを処理しますが、それらはスーパーユーザチェックを不適切に実施した後でのみ行っていました。
</p>
<li>更新または削除アクションのロジカルレプリケーション中に、ドロップされた列を無視するようになりました。  (Onder Kalaci, Shi Yu) (11)</li>
<p>
テーブルにそのような列が含まれている場合、REPLICA IDENTITY FULL オプションを使用したレプリケーションは失敗していました。
</p>
</ol>

<div>
<a href="https://www.sraoss.co.jp/prod_serv/support/pgsql-mainte/?utm_source=sraoss-techblog&utm_medium=referral&utm_campaign=under-article-pgsql" rel="noopener" style="color:initial;" target="_blank" class="no-ext"></p>
<div style="background-color:#DAEFF6; padding:20px; border-radius:8px; text-align:center;">
SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。<br />
詳しくは<strong style="color:#2581c4;">弊社ホームページ</strong>をご覧ください。
</div>
<p></a>
</div>

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 11.19 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-19/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Mon, 06 Mar 2023 00:00:46 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.18]]></category>
		<category><![CDATA[PostgreSQL 11.19]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=12107</guid>

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

<div>
<a href="https://www.sraoss.co.jp/prod_serv/support/pgsql-mainte/?utm_source=sraoss-techblog&utm_medium=referral&utm_campaign=under-article-pgsql" rel="noopener" style="color:initial;" target="_blank" class="no-ext"></p>
<div style="background-color:#DAEFF6; padding:20px; border-radius:8px; text-align:center;">
SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。<br />
詳しくは<strong style="color:#2581c4;">弊社ホームページ</strong>をご覧ください。
</div>
<p></a>
</div>

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 11.18 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-18/</link>
		
		<dc:creator><![CDATA[高塚 遥 (Haruka Takatsuka)]]></dc:creator>
		<pubDate>Wed, 30 Nov 2022 23:01:05 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQ]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.17]]></category>
		<category><![CDATA[PostgreSQL 11.18]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=11847</guid>

					<description><![CDATA[このリリースは 11.17 からの修正リリース（2022年11月10日リリース）です。 11.X からのアップデートではダンプ、リストアは不要です。 しかしながら、11.14 よりも前のバージョンからアップデートする場合 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 11.17 からの修正リリース（2022年11月10日リリース）です。<br />
11.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、11.14 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/11-14/ ">11.14 のリリース情報</a>も参照してください。</p>
<p><span id="more-11847"></span></p>
<h3>PostgreSQL 11.17 から 11.18 への変更点</h3>
<p>15.1、14.6、13.9、12.13、11.18、10.23 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>大きなテーブルの最初以外のセグメントを削除できない問題が修正されました。  (Tom Lane) (15)</li>
<p>
PostgreSQL は大きなテーブルを複数のファイル（通常 1ファイルあたり 1GB のファイル）に分割します。 テーブルを削除するロジックが壊れており、一時テーブルの削除と、通常テーブルを削除する WAL の再生の 2つのケースで、そのようなファイルの最初のファイル以外を削除しそこなうことがありました。 数ギガバイトの一時テーブルを日常的に作成するアプリケーションは、重大なディスク領域のリークを被る可能性がありました。
</p>
<p>
孤立した一時テーブルファイルは postmaster の起動時に削除されるため、15.1 に更新するだけで、一時テーブルのストレージのリークが解消されます。しかし、15.0 を使用中にデータベースがクラッシュし、その直前に大きなテーブルが削除された可能性がある場合、データベースディレクトリに「NNNN.NN」というパターンに従った名前のファイルがないか確認することが推奨されます。「NNNN」（「.NN」サフィックスなし）という名前の一致するファイルがない場合、これらのファイルは手動で削除する必要があります。
</p>
<li>更新可能ビューへの INSERT で、複数行 VALUES句にある DEFAULTトークンの処理が修正されました。  (Tom Lane) (15)(14)(13)(12)(11)(10)</li>
<p>
この障害により、「ERROR:  cache lookup failed for type ..」エラーが発生したり、古いブランチではクラッシュの原因になることもありました。
</p>
<pre>
（障害発生例）
db=# CREATE TABLE t2 (a int, b text);
db=# CREATE TABLE t2_hist (ts timestamptz DEFAULT now(), a int, b text);
db=# CREATE VIEW v2 AS SELECT * FROM t2;
db=# CREATE RULE r_t2_log AS ON INSERT TO v2
       DO ALSO INSERT INTO t2_hist (a,b) VALUES (NEW.a, NEW.b);
db=# INSERT INTO v2 VALUES (1, DEFAULT), (10, DEFAULT);
ERROR:  cache lookup failed for type 0
</pre>
<li>「ON SELECT」でない「_RETURN」という名前のルールが禁止されました。  (Tom Lane) (15)(14)(13)(12)(11)(10)</li>
<p>
これにより、ビューの「ON SELECT」ルールと他のルールとの間の混乱が回避されます。
</p>
<li>定数初期値で「SEARCH BREADTH FIRST」を使用する問い合わせがEXPLAIN VERBOSE でエラーを出さないようになりました。  (Tom Lane) (15)(14)</li>
<pre>
（問い合わせ自体は実行できる）
db=# WITH RECURSIVE cte4 AS (
       SELECT 1 AS x UNION ALL SELECT x + 1 FROM cte4
     ) SEARCH BREADTH FIRST BY x SET y
     SELECT * FROM cte4 LIMIT 3;
 x |   y
---+-------
 1 | (0,1)
 2 | (1,2)
 3 | (2,3)
(3 rows)

（explain verbose を付けるとエラーになる）
db=# explain (verbose) WITH RECURSIVE cte4 AS (
       SELECT 1 AS x UNION ALL SELECT x + 1 FROM cte4
     ) SEARCH BREADTH FIRST BY x SET y
     SELECT * FROM cte4 LIMIT 3;
ERROR:  record type has not been registered
</pre>
<li>外部テーブルパーティションを含むパーティションテーブルでMERGE の使用が禁止されました。  (&Aacute;lvaro Herrera) (15)</li>
<p>
MERGE で外部テーブルを直接ターゲットにすることは既に禁止されていましたが、このケースはサポートされておらず、理解できないエラーが発生していました。
</p>
<p>
「ERROR:  unexpected operation: ...」のようなエラーが出ることが報告されました。修正により「ERROR:  cannot execute MERGE on relation ...」が出るようになります。
</p>
<li>ALTER TABLE ATTACH PARTITION 実行中に行われるパーティションごとの外部キー制約の構築が修正されました。  (Jehan-Guillaume de Rorthais, &Aacute;lvaro Herrera) (15)(14)(13)(12)</li>
<p>
以前は、新しく追加されたパーティションに対して、不正確または重複した制約が作成されることがありました。
</p>
<li>パーティションテーブルまたは継承されたテーブルの拡張統計を参照する際のプランナエラー発生が修正されました。  (Richard Guo, Justin Pryzby) (15)</li>
<p>
問い合わせ実行に対して「ERROR:  cache lookup failed for statistics object」というエラーが発生する場合がありました。
</p>
<li>GINインデックスの高速挿入パスでの WAL操作の順序の誤りが修正されました。  (Matthias van de Meent, Zhang Mingli) (15)(14)(13)(12)(11)(10)</li>
<p>
この間違いは、PostgreSQLのコア部分で悪影響を与えることは知られていませんが、一部の拡張機能で問題が発生していました。
</p>
<li>トランザクションの開始とそのサブトランザクションの開始の間からリプレイが開始される場合の、論理デコードのバグが修正されました。  (Masahiko Sawada, Kuroda Hayato) (15)(14)(13)(12)(11)(10)</li>
<p>
これらのエラーは、デバッグビルドでのアサート失敗や、メモリリークを引き起こす可能性がありました。
</p>
<li>論理デコード中に、より多くの場所で割り込みを受け付けるようになりました。  (Amit Kapila, Masahiko Sawada) (15)(14)(13)(12)(11)(10)</li>
<p>
これにより、レプリケーションワーカのシャットダウンが遅いという問題が改善されます。
</p>
<li>レプリケーションワーカで外部テーブルのパーティションにデータ同期を試みる動作が防止されました。  (Shi Yu, Tom Lane) (15)(14)(13)</li>
<p>
パーティションテーブルは外部テーブルをパーティションとすることができますが、そのようなパーティションへの論理レプリケーションは今のところサポートされていません。実行しようとすると論理レプリケーションワーカのプロセスはこれまでクラッシュしていましたが、エラーを出すようになりました。
</p>
<li>レプリケーションワーカでの関数構文エラー後のクラッシュを回避するようになりました。  (Maxim Orlov, Anton Melnikov, Masahiko Sawada, Tom Lane) (15)(14)(13)(12)(11)(10)</li>
<p>
論理レプリケーションワーカで実行された SQL言語または PL/pgSQL言語のCREATE FUNCTION または DO コマンドで構文エラーが発生した場合、ワーカプロセスは nullポインターの逆参照またはアサート失敗でクラッシュしていました。
</p>
<p>
サブスクリプション側にそのようなトリガを定義した場合に現象が報告されました。
</p>
<li>アーカイバモジュールのシャットダウンコールバックの二重呼び出しを回避するようになりました。  (Nathan Bossart, Bharath Rupireddy) (15)</li>
<li>テーブルアクセスメソッドを持たないテーブルへのアクセスに対して、プラン作成時の検査が追加されました。  (Tom Lane) (15)(14)(13)(12)</li>
<p>
これにより、例えば「ON SELECT」ルールが欠落しているビューの使用など、一部のカタログ破損シナリオにおけるクラッシュが防止されます。そのような場合には「ERROR:  cannot open relation ...」が出るようになりました。
</p>
<li>共有メモリ状態が破損しているときの postmaster のクラッシュが防止されました。  (Tom Lane) (15)(14)(13)(12)(11)(10)</li>
<p>
postmasterプロセスは、共有メモリが破損した場合にも存続し、データベースの再起動を行うはずですが、コードのある 1箇所で対応が不十分でした。
</p>
<li>libpq がパイプラインモードのときに単一行モードを正しく処理するように修正されました。  (Denis Laxalde) (15)(14)</li>
<p>
パイプラインモードも有効である場合、単一行フラグが正しいタイミングでリセットされませんでした。
</p>
<li>コマンドラインクエリがキャンセルされた時の psql の終了ステータスが修正されました。  (Peter Eisentraut) (15)</li>
<p>
クエリがキャンセルされた場合、「psql -c query」は正常終了していました。他のエラーの場合と同様に、ゼロ以外のステータスで終了するようになりました。
</p>
<li>pg_basebackup でクロスプラットフォームのテーブルスペースの再配置を許可するようになりました。  (Robert Haas) (15)(14)(13)(12)(11)(10)</li>
<p>
--tablespace-mapping のリモートパスを Unixスタイルまたは Windowsスタイルの絶対パスにすることができるようになりました。これは、ソースサーバがローカルシステムとは異なる OS 上にある可能性があるためです。
</p>
<li>一部の CHECK制約に付加されたコメントを pg_dump がダンプできない問題が修正されました。  (Tom Lane) (15)</li>
<li>CREATE DATABASE で oidパラメータが 2^31 を超えることができるように修正されました。  (Tom Lane) (15)</li>
<p>
このパラメータの最大値を見落としにより、ソースインストールにそれより大きい OID を持つデータベースが含まれている場合、pg_upgrade が成功しませんでした。
</p>
<li>pg_stat_statements で既に解放されたメモリへのアクセスが修正されました。  (zhaoqigui) (15)(14)(13)(12)(11)(10)</li>
<p>
これは、拡張問い合わせプロトコルで発行された ROLLBACK コマンドをトラックしている時に発生します。デバッグビルドでは、これによりアサート失敗が発生しました。製品ビルドでは、目立った問題は発生しません。しかし、解放されたメモリが既に再利用されていた場合、クエリ文字列にゴミデータが格納される結果になると考えられます。
</p>
<li>LLVM 15 との非互換性が修正されました。  (Thomas Munro, Andres Freund) (15)(14)(13)(12)(11)</li>
<li>どのようなマシンであってもスピンロックのために__sync_lock_test_and_set() が使えるようになりました。  (Tom Lane) (15)(14)(13)(12)(11)(10)</li>
<p>
この GCC ビルトイン関数をサポートしているコンパイラを使っていさえすれば、新しいマシンアーキテクチャへポーティングが簡単になります。
</p>
<li>最近の macOS で起きるコンパイル障害を避けるために、シンボル「REF」が「REF_P」にリネームされました。  (Tom Lane) (15)(14)(13)(12)(11)(10)</li>
<li>コンパイル時の非推奨の警告を避けるため、sprintf が使われなくなりました。  (Tom Lane) (15)(14)(13)(12)</li>
<li>タイムゾーンデータファイルが tzdata release 2022f に更新されました。チリ、フィジー、イラン、ヨルダン、メキシコ、パレスチナ、シリアの夏時間法が変更と、チリ、クリミア、イラン、メキシコの歴史的な修正が含まれます。   (15)(14)(13)(12)(11)(10)</li>
<p>
また、Europe/Kiev ゾーンは Europe/Kyiv にリネームされました。さらに、以下のゾーンは 1970年以来承認されている時計のある人口の多い近傍のゾーンに併合されました:
</p>
<pre>
Antarctica/Vostok、Asia/Brunei、Asia/Kuala_Lumpur、Atlantic/Reykjavik、
Europe/Amsterdam、Europe/Copenhagen、Europe/Luxembourg、Europe/Monaco、
Europe/Oslo、Europe/Stockholm、
Indian/Christmas、Indian/Cocos、Indian/Kerguelen、Indian/Mahe、Indian/Reunion、
Pacific/Chuuk、Pacific/Funafuti、Pacific/Majuro、Pacific/Pohnpei、
Pacific/Wake、Pacific/Wallis
</pre>
<p>
（これは Arctic/Longyearbyen、Atlantic/Jan_Mayen、Iceland、Pacific/Ponape、Pacific/Truk、Pacific/Yap のうちの一つに既にリンクされているゾーンにも、間接的に影響します。）1970年以降に主張されたこれらゾーンとの差異が誤りであるようだと判明した後、America/Nipigon、America/Rainy_River、America/Thunder_Bay、Europe/Uzhgorod、Europe/Zaporozhye も近傍のゾーンに併合されました。
</p>
<p>
これらの全てのケースでは以前のゾーンの名前は別名として残されています。しかし、実際のデータはマージされたゾーンにあります。これらのゾーン併合は 1970年以前のタイムゾーンの歴史を失うことになります。これは timestamptz 表示の一貫性を期待するアプリケーションには問題となるかもしれません。例えば、保存されている値が「1944-06-01 12:00 UTC」の場合、以前は「1944-06-01 13:00:00+01」と表示されましたが、Europe/Stockholm が選択されている場合は「1944-06-01 14:00:00+02」となります。
</p>
<p>
より古いゾーンデータをリストアするオプションを付けたタイムゾーンデータファイルを作ることも可能ですが、この選択はたくさんの他の古い（かつ典型的には証明に乏しい） ゾーンデータを追加してしまうことになります。結果として、この上位変更を受け入れる場合よりも、以前のリリースの全体の変更は多くなってしまいます。
</p>
<p>
PostgreSQL は tzdb の移行を推奨してきましたが、知る限りではほとんどの主要なオペレーティングシステムのディストリビューションでも同様のことをやっています。しかしながら、もしこれらの変更があなたのアプリケーションに重要な問題を起こすならば、可能性のある解決方法は tzdb の後方互換オプションを使ってタイムゾーンデータファイルをローカルにビルドしてインストールする方法です（PACKRATDATAオプションと PACKRATLISTオプションを見てください）。
</p>
<li>VACUUM と並行に実行される更新で稀に起きていた PANIC が回避されました。  (Tom Lane, Jeff Davis) (14)(13)(12)</li>
<p>
並行する VACUUM が UPDATE または DELETE で更新中のページの全ての可視フラグビットをセットするなら、その更新コマンドはそのビットをもう一度クリアする必要があります。しかし、いくつかのコードパスはそれに失敗し、PANIC で終了していました。
</p>
<p>
これはバージョン 14 と 15 で起きる可能性があることが知られています。それより前のブランチでは顕在化しないかもしれません。
</p>
<li>AFTERトリガに対してタプルを保存する際の資源管理のバグが修正されました。  (Tom Lane) (14)(13)(12)</li>
<p>
正常な状態において「ERROR:  tupdesc reference ... is not owned by resource owner ...」というエラーが出た後、「PANIC:  ERRORDATA_STACK_SIZE exceeded」によるサービス全体の停止または再起動が発生しました。
</p>
<li>パーティションごとの外部キー制約に対する制約名の生成が修正されました。  (Jehan-Guillaume de Rorthais) (14)(13)(12)</li>
<p>
最初に与えられた名前がそのパーティションの何らかの制約として既に使われていたら、新しい制約名が選ばれますが、意図した名前になっていませんでした。誤って「リレーション名__fkey」という制約名が生じていました。
</p>
<li>パーティションインデックスを作るときの、インデックスの式と述語の誤った照合が修正されました。  (Richard Guo, Tom Lane) (14)(13)(12)(11)</li>
<p>
パーティションテーブルにインデックスを作るときに、定義が一致する各パーティション上の既存インデックスを識別して、それを子インデックスとして取り込みしようとします。このとき、式の照合が正しく行われず、パーティション上の利用可能な既存インデックスが無視されて、重複したインデックスが作成されることがありました。
</p>
<li>スタンバイ昇格後の WAL破損を防止するようになりました。  (Dilip Kumar, Robert Haas) (14)(13)(12)(11)(10)</li>
<p>
アーカイブリカバリ中の（スタンバイモードではない）PostgreSQLインスタンスが昇格するときに、最後に読み込もうとした WALセグメントが部分レコードで終わっていた場合、新しいタイムライン上に無効な WAL セグメントを書き込んでいました。
</p>
<li>論理デコード中に、間違ったスナップショットでシステムカタログを検査することを防止するようになりました。  (Masahiko Sawada) (14)(13)(12)(11)(10)</li>
<p>
システムカタログを変更するトランザクションの途中でデコードが開始されると、デコーダがそれを認識できないことがあり、その結果、カタログ検索でそのトランザクションが進行中として扱われませんでした。
</p>
<li>パーティションテーブルのレプリカアイデンティティ設定についての無意味なチェックが除去されました。      (Hou Zhijie) (14)(13)</li>
<p>重要なのはリーフパーティションのレプリカアイデンティティの設定であり、それが親テーブルに設定されていない場合にエラーを投げる必要はありません。
</p>
<li>SQL関数に渡される読み書き可能な拡張データムの取り扱いを修正しました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
インライン化されていない SQL関数が 2つ以上の場所で引数を使用し、そのうちの 1箇所で読み書き可能なデータムを上書きで変更できると期待した場合、後でそのパラメータを使用した時に間違った値が観測されました。
</p>
<p>
配列を引数に取る再帰的な SQL関数の実行で、誤った問い合わせ結果が生じるケースが報告されました。PostgreSQL本体内では拡張データム機構は、配列と複合型の値に対してのみ使用されています。
</p>
<li>circle型の等価比較で NaN を適切に処理するように修正されました。  (Ranier Vilela) (14)(13)(12)</li>
<p>
左側の円の半径が浮動小数点数の NaN であった場合、中心座標が同じで任意の半径を持つ円と等しいと見なされるようになりました。
</p>
<li>Snowball辞書で過度に長い単語を語幹処理しないようになりました。  (Olly Betts, Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
入力単語が 1000バイトを超える場合、Snowballコードを通すのではなく、大文字小文字を揃えた後、そのまま返すようになりました。
</p>
<p>
この制限は、トルコ語の語幹機能における recursion-to-stack-overflow への既知問題から保護し、Snowballの語幹機能におけるその他の安全性や性能の問題に対する良い保険になると考えられます。
</p>
<li>文字列比較における解放後メモリアクセスが修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
文字列比較関数の不適切なメモリ管理により、もはや割り当てられていないバッファに書き込みが生じて、そのメモリを現在使用している何かが壊れる可能性がありました。
</p>
<p>
これは、かなり長い文字列（1kB以上）で ICU照合順序が使用されている場合にのみ、発生しました。
</p>
<li>スタックオーバーランに至るまでの再帰に対するさらなる防御（検査コード）が追加されました。  (Richard Guo, Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
巨大な SQL文で「ERROR:  stack depth limit exceeded」のエラーを出さずに、バックエンドプロセスがクラッシュする動作が報告されていました。
</p>
<li>非常に小さな work_mem と大きなタプル（1行が大きい）の組み合わせでハッシュテーブルのサイズを選択するときの、誤動作を回避するようになりました。  (Zhang Mingli) (14)(13)</li>
<li>autovacuum launcherプロセスでメモリリークを回避するようになりました。  (Reid Thompson) (14)(13)(12)(11)(10)</li>
<p>
以前からのバグであるにもかかわらず現場からの報告がないことから、この問題はバージョン15 より前のブランチでは顕在化しないと思われますが、確かではないため、各バージョン系列にバックパッチが行われました。
</p>
<li>PL/pgSQL が RECORD として宣言されたパラメータを処理する能力が改善されました。  (Tom Lane) (14)(13)(12)(11)</li>
<p>
多相パラメータに対して行うのと同じように、セッション中に RECORDパラメータに渡される各具象型に対して、個別の関数キャッシュ項目を構築するようになりました。これにより、以前は「ERROR:  type of parameter ... does not match that when preparing the plan」などのエラーで失敗していたいくつかの使用法が動作するようになりました。
</p>
<li>libpq内の NULL のコネクションポインタに対する欠落していた検査が追加されました。  (Daniele Varrazzo, Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
libpq の関数は、NULL の PGconn 引数を検査して、クラッシュする代わりにエラーを出す、という慣習があります。PQflush() と PQisnonblocking() でこれが守られていなかったため修正されました。
</p>
<li>ecpgで、複数の varchar または bytea 変数が同じ宣言内で宣言されている時の変数ストレージクラスの省略を修正しました。  (Andrey Sokolov) (14)(13)(12)(11)(10)</li>
<p>
これまで「static varchar str1[10], str2[20], str3[30];」を以下のように変換していました。
</p>
<pre>
（不適切な出力例）
static struct varchar_1  { int len; char arr[ 10 ]; }  str1 ;
       struct varchar_2  { int len; char arr[ 20 ]; }  str2 ;
       struct varchar_3  { int len; char arr[ 30 ]; }  str3 ;
</pre>
<li>postgres_fdwで、EvalPlanQual の実行計画むけに構築されたターゲットリストが、必要なすべての列を持つことになりました。  (Richard Guo, Etsuro Fujita) (14)(13)(12)(11)(10)</li>
<p>
これにより「ERROR: variable not found in subplan target list」エラーが防止されます。EvalPlanQual は READ COMMITTED 隔離レベルの問い合わせで使われる処理です。
</p>
<li>プラットフォームの uuid_create() 関数からの不要な出力を拒否するようになりました。  (Nazir Bilal Yavuz) (14)(13)(12)(11)(10)</li>
<p>
uuid-osspモジュールでは libc の uuid_create() がバージョン1 の UUID を生成すると期待していますが、最近の NetBSD のリリースでは、代わりにバージョン4 の (ランダムな) UUID を生成します。これを検査して、そうであればエラーを出すようになりました。
</p>
<p>
ドキュメントの、NetBSD の実装が uuid-ossp に使用可能という記載も削除されました。（バージョン4 の UUID が必要な場合には、uuid-ossp モジュールではなく、本体付属の関数 gen_random_uuid() を使ってください。）
</p>
<li>新しい Perlテストモジュールが標準インストールに含まれるようになりました。  (&Aacute;lvaro Herrera) (14)(13)(12)(11)(10)</li>
<p>
PostgreSQL/Test/Cluster.pm と PostgreSQL/Test/Utils.pm をバージョン15 より前のブランチの標準インストールファイルに追加しました。これは、古いブランチで新しく書かれたテストコードを使いたい拡張のためです。
</p>
<li>NetBSD で、postmaster 起動時に動的シンボル解決を強制するようになりました。  (Andres Freund, Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
これにより、NetBSD 10 におけるダイナミックリンカでのデッドロックの危険性を回避できるようになりました。
</p>
<li>clang 15 以降のコンパイラからの警告が出ないようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<li>VACUUM が btreeインデックスでのページ削除でページの親ダウンリンクを見つけるのに失敗した場合でも進行するように修正されました。  (Peter Geoghegan) (13)(12)(11)(10)</li>
<p>
エラーを投げるのではなく、むしろ問題を記録し、空のページを削除せずに続行するようになりました。以前は、バグのある演算子クラスまたは破損したインデックスにより、インデックスのバキューム処理がいつまでも完了せず、最終的に XID周回の問題につながっていました。
</p>
<p>
以下メッセージが ERROR から LOG に変更されます。「failed to re-find parent key in index ... for deletion target page ...」
</p>
<li>継承された更新で稀に生じる MULTIEXPR_SUBLINK のサブプランのエラーが修正されました。  (Tom Lane) (13)(12)(11)(10)</li>
<p>
構文 UPDATE tab SET (c1, ...) = (SELECT ... ) を継承テーブルやパーティション化された対象テーブルに使用すると、子テーブルが十分に異なっている場合、失敗することがありました。
</p>
<p>
これは通常、エグゼキュータでの一貫性チェックの失敗のエラーとして現れます。しかし、クラッシュや不正なデータ更新（すなわち論理的なデータ破損）も起こり得ます。
</p>
<p>
本構文の UPDATE に対して、「ERROR:  invalid attribute number ...」などの予期せぬエラーの発生が報告されました。
</p>
<li>外側の問い合わせがグループ化セットを持つ場合、FROM のないサブクエリの平坦化を回避するようになりました。  (Tom Lane) (11)(10)</li>
<p>
この誤りは、アサート失敗や「ERROR:  variable not found in subplan target list」 などのプランナエラーにつながる可能性があります。
</p>
</ol>

<div>
<a href="https://www.sraoss.co.jp/prod_serv/support/pgsql-mainte/?utm_source=sraoss-techblog&utm_medium=referral&utm_campaign=under-article-pgsql" rel="noopener" style="color:initial;" target="_blank" class="no-ext"></p>
<div style="background-color:#DAEFF6; padding:20px; border-radius:8px; text-align:center;">
SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。<br />
詳しくは<strong style="color:#2581c4;">弊社ホームページ</strong>をご覧ください。
</div>
<p></a>
</div>

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 11.17 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-17/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Mon, 05 Sep 2022 01:45:15 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.16]]></category>
		<category><![CDATA[PostgreSQL 11.17]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=10956</guid>

					<description><![CDATA[このリリースは 11.16 からの修正リリース（2022年8月11日リリース）です。 11.X からのアップデートではダンプ、リストアは不要です。 しかしながら、11.14 よりも前のバージョンからアップデートする場合に ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 11.16 からの修正リリース（2022年8月11日リリース）です。<br />
11.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、11.14 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/11-14/ ">11.14 のリリース情報</a>も参照してください。</p>
<p><span id="more-10956"></span></p>
<h3>PostgreSQL 11.16 から 11.17 への変更点</h3>
<p>14.5、13.8、12.12、11.17、10.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>拡張のスクリプトが、拡張に属していないオブジェクトを置換しないようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
この変更は、拡張に属さない既存オブジェクトがある場合に、拡張のスクリプトが CREATE OR REPLACE を行うことを防止します。また、同じ状況での CREATE IF NOT EXISTS も防止します。 これにより、敵対的なデータベースユーザが拡張のオブジェクトの所有者になって、それを変更して将来の他ユーザによるオブジェクト使用を危機にさらすという、トロイの木馬型の攻撃を防ぐことができます。 副次的な利点として、意図しないオブジェクトを誤って置換してしまうリスクも軽減されます。(CVE-2022-2625)
</p>
<li>スタンバイサーバでの「CREATE DATABASE」WALレコードのリプレイが修正されました。  (Kyotaro Horiguchi, Asim R Praveen, Paul Guo) (14)(13)(12)(11)(10)</li>
<p>
スタンバイサーバがデータベース作成の WALレコードをリプレイする時に、テーブルスペースのディレクトリが見つからないことがあります。 本パッチ適用前は、このような場合、スタンバイはリカバリに失敗していましたが、このようなディレクトリが合法的に欠落している可能性がありました。テーブルスペースを（通常のディレクトリとして）作成し、リプレイが一貫した状態に達したら、再び削除されていることを確認する動作に変更されました。
</p>
<li>「構内」テーブルスペースがサポートされました。  (Thomas Munro, Michael Paquier, &Aacute;lvaro Herrera) (14)(13)(12)(11)(10)</li>
<p>
通常、PostgreSQL のテーブルスペースは、他のファイルシステム上のディレクトリへのシンボリックリンクですが、この変更により、データベースクラスタディレクトリ内の単なるディレクトリにすることができます。
</p>
<p>
これはテストには便利な仕組みです。さらに、CREATE DATABASE リプレイの修正（前項の修正）で、欠落しているテーブルスペースを構内テーブルスペースとして一時的に作成するために必要となります。
</p>
<p>
設定パラメータ allow_in_place_tablespaces が追加されています。以下のように使用できます。
</p>
<pre>
（以下を実行すると pg_tblspc 以下にテーブルスペース用ディレクトリが作られる）
db1=# SET allow_in_place_tablespaces TO on;
db1=# CREATE TABLESPACE sp1 LOCATION '';
CREATE TABLESPACE
</pre>
<li>CREATE INDEX における権限チェックが修正されました。  (Nathan Bossart, Noah Misch) (14)(13)(12)(11)(10)</li>
<p>
CVE-2022-1552 むけの修正により、CREATE INDEX が演算子クラスやその他のオブジェクトの検索を実行する際に、以前は呼び出しユーザのパーミッションを適用していたところで、テーブル所有者のパーミッションを適用するようになっていました。pg_dump はパーミッションを再度付与する前に CREATE INDEX を発行するため、これによりダンプ/リストアのシナリオが壊れていました。
</p>
<p>
本修正で問題を回避するように調整されました。
</p>
<li>拡張問い合わせプロトコルでは、トランザクションブロック内で実行できないCREATE DATABASE 等のコマンド後に、即時コミットを強制するようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
クライアントがそのようなコマンドの直後に Sync メッセージを送信せず、代わりに別のコマンドを送信した場合、そのコマンドで障害が発生すると、直前のコマンドがロールバックされ、通常ディスク上に矛盾した状態が残りました（欠落しているデータベースディレクトリや余分なデータベースディレクトリなど）。
</p>
<p>
そのような状況を防ぐためのメカニズムは、簡易問い合わせメッセージ内の複数コマンドに対しては機能しますが、拡張問い合わせの一連のメッセージに対しては機能しません。現在動作しているユースケースを壊さずに矛盾を防ぐため、そのようなコマンドの後に暗黙のコミットを強制するものとなりました。
</p>
<li>トランザクションの可視性をチェックする際の競合状態が修正されました。  (Simon Riggs) (14)(13)(12)(11)(10)</li>
<p>
内部実装関数 TransactionIdIsInProgress(xid) が、対象のトランザクションが可視とみなされる前に「false」を報告し、さまざまな誤動作を引き起こす可能性がありました。競合状態のウィンドウは通常、非常に狭いですが、同期レプリケーションを使用すると同期レプリカの待機がそのウィンドウ内で発生するため、より広くなります。
</p>
<p>
代表的な誤動作は以下のエラーが出ることです。
</p>
<pre>
ERROR:  t_xmin is uncommitted in tuple to be updated
</pre>
<li>最上位以外に集合を返す関数を含む式でソートした場合の誤った計画が修正されました。  (Richard Guo, Tom Lane) (14)(13)</li>
<p>
以下ような形状の問い合わせについて、予期せぬエラー「ERROR:  set-valued function called in context that cannot accept a set」が生じるケースが報告されました。
</p>
<pre>
SELECT unnest(ARRAY[]::integer[]) + 1 AS pathkey
  FROM ta JOIN tb ON ta.c1 = tb.c1 ORDER BY pathkey
</pre>
<li>拡張統計情報の誤った権限検査コードが修正されました。  (Richard Guo) (14)</li>
<p>
ユーザが不十分な SELECT権限しか持たないテーブルに拡張統計情報がある場合、一部の問い合わせが「ERROR:  permission denied ...」ではなく、「ERROR:  unrecognized node type」で失敗していました。
</p>
<li>ブール値式の MCV（最頻値）型の統計情報を処理するために、拡張統計情報の仕組みが修正されました。  (Tom Lane) (14)</li>
<p>
統計収集は正常に動作しますが、WHERE にその式を含む問い合わせは、プラン作成時に「ERROR:  unknown clause type ...」で失敗していました。
</p>
<pre>
（エラー発生例）
db=# CREATE TABLE t9 (a int, b int);
db=# CREATE STATISTICS stat_ex1 ON
       (CASE a WHEN 1 THEN true ELSE false END), b FROM t9;
db=# INSERT INTO t9 SELECT g % 10, g FROM generate_series(1,10000) g;
db=# ANALYZE t9;
db=# SELECT * FROM t9 WHERE (CASE a WHEN 1 THEN true ELSE false END) AND b = 2;

ERROR:  unknown clause type: 134
</pre>
<li>配列変数に MCV（最頻値）タイプの拡張統計情報がある場合に「constant = ANY(array)」句に対してプランナでクラッシュが生じていて、修正されました。  (Tom Lane) (14)(13)</li>
<pre>
（障害発生例）
db=# CREATE TABLE t10 (c int, a int[]);
db=# CREATE STATISTICS stat_ex10 (mcv) ON c, a FROM t10;
db=# INSERT INTO t10 SELECT g, ARRAY[g] FROM generate_series(1, 10) g;
db=# ANALYZE t1
db=# SELECT * FROM t10 WHERE c = ANY (ARRAY[1,2,3]) AND 1 = ANY(a);

server closed the connection unexpectedly
</pre>
<li>「ALTER TABLE ... ENABLE/DISABLE TRIGGER」がパーティションテーブル上のトリガの再帰を正しく処理するように修正されました。  (&Aacute;lvaro Herrera, Amit Langote) (14)(13)(12)(11)</li>
<p>
場合によっては、コマンドがトリガを持たない子パーティションでトリガを調整しようとするため、「ERROR:  trigger does not exist」が発生することがありました。
</p>
<li>拡張統計情報の計算中に ANALYZE をキャンセルできるようになりました。  (Tom Lane, Justin Pryzby) (14)</li>
<p>
高コストな統計情報対象を伴うシナリオでは、キャンセルできないソート操作に何秒も費やす可能性がありました。
</p>
<li>jsonpath型の構文エラーメッセージが改善されました。  (Andrew Dunstan) (14)(13)(12)</li>
<p>
「ERROR:  syntax error, unexpected IDENT_P at or near " " of jsonpath input」のような、パーサ実装のトークン名を伴うメッセージが出ていました。
</p>
<li>pg_stop_backup() がセッションの状態を適切にクリーンアップするようになりました。  (Fujii Masao) (14)(13)(12)(11)(10)</li>
<p>
これまで省略されていたため、セッションの後半でアサート失敗やクラッシュを引き起こす可能性がありました。
</p>
<li>ゼロ次元の配列の引数を適切に処理するように trim_array() が修正されました。  (Martin Kalcher) (14)</li>
<p>
不正メモリアクセスにより、潜在的にクラッシュが生じる可能性がありました。
</p>
<li>「FOR [KEY] UPDATE/SHARE」句における結合エイリアスのマッチングが修正されました。  (Dean Rasheed) (14)(13)(12)(11)(10)</li>
<p>
稀なケースでは、誤解を招くエラーが報告されることがありました。
</p>
<p>
「ERROR:  FOR UPDATE cannot be applied to a join」とするべきところで、「ERROR:  relation "..." in FOR UPDATE clause not found in FROM clause」が出力される動作が報告されました。
</p>
<li>多すぎる列を持つ FROM の中の ROW() 表現と関数を拒絶するようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
おおよそ 1600列を超えるケースはサポートされておらず、必ず実行に失敗します。しかしながら、32K を超える列を持った問い合わせによって、アサート失敗またはクラッシュが発生する以前のコードが一部ありました。これを避けるために構文解析するときに検査するようになりました。
</p>
<li>ビューが作られて複合型の列がドロップされた場合、複合型を返す FROM の中の関数を使っているビューのダンプが修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
ダンプされたビューはこの関数に対する過剰な列エイリアスを持っているため、ダンプ／リストアや pg_upgrade でのエラーを引き起こしました。
</p>
<pre>
（障害動作例）
db=# CREATE TYPE typ18 AS (c1 int, c2 int, c3 int);
db=# CREATE VIEW v18 AS SELECT * FROM fn18();
db=# ALTER TYPE typ18 DROP ATTRIBUTE c2;
db=# SELECT pg_get_viewdef('v18', true); -- ダンプ時の出力を確認
          pg_get_viewdef
----------------------------------
  SELECT fn18.c1,                +
     fn18.c2,                    +
     fn18.c3                     +
    FROM fn18() fn18(c1, c2, c3);
(1 row)
db=# SELECT fn18.c1, fn18.c2, fn18.c3 FROM fn18() fn18(c1, c2, c3);
ERROR:  table "fn18" has 2 columns available but 3 columns specified
</pre>
<li>論理レプリケーションの walsender で、同セッション内からの入れ子のベースバックアップ取得処理を禁止するようになりました。  (Fujii Masao) (14)(13)(12)(11)(10)</li>
<p>
クラッシュやアサート失敗を起こす可能性がありました。
</p>
<li>論理レプリケーションのサブスクライバのメモリリークが修正されました。  (Hou Zhijie) (14)(13)(12)(11)(10)</li>
<li>ターゲットテーブルがパーテション化されている場合、論理レプリケーションのレプリカアイデンティティ（REPLICA IDENTITY）の検査が修正されました。  (Shi Yu, Hou Zhijie) (14)(13)</li>
<p>
子パーティションについてのレプリカアイデンティティ列の検査が抜け落ちていました。
</p>
<p>
サブスクライバ側でアサート失敗を引き起こす動作が報告されました。
</p>
<li>論理レプリケーションにおいてパブリッシャのスキーマを変更した後にサブスクライバでキャッシュされたスキーマデータの更新に失敗していて、これが修正されました。  (Shi Yu, Hou Zhijie) (14)(13)</li>
<li>「BRIN_EVACUATE_PAGE」フラグを正しく処理するように、WAL一貫性の検査ロジックが修正されました。  (Haiyang Wang) (14)(13)(12)(11)(10)</li>
<li>共有ハッシュテーブル管理における誤ったアサート検査が修正されました。  (Thomas Munro) (14)(13)(12)(11)</li>
<li>min_dynamic_shared_memory がデフォルトでない値にセットされた時に起きるアサート失敗が回避されました。  (Thomas Munro) (14)</li>
<li>SPI_commit() のなかでコミット時のエラーが起きた時、呼び出し元がクリーンアップしてくれることを期待せずに自動で行うようになりました。  (Peter Eisentraut, Tom Lane) (14)(13)(12)(11)</li>
<p>
適切なクリーンアップには複雑で低レベルな機能を必要とします。従って、どの既知の呼び出し元もクリーンアップしないことがあり得ます。このために、手続き言語が COMMIT を発行したが（例えば遅延制約検査などで）エラーが起きてしまった場合に誤動作を招きます。
</p>
<p>
これを改善するために SPI_commit() を次のように再定義しました。即ち、前トランザクションの特性を保存せずに新しいデフォルトトランザクションの特性を取ること以外は、SPI_commit_and_chain() と等価な新しいトランザクションを開始するものとしました。この変更を透過的にするため、SPI_start_transaction() を no-op（何もしない動作）に再定義しました。全ての SPI_commit() の既知の呼び出し元は直後に SPI_start_transaction() を呼びます。これにより全ての呼び出し元は本変更の影響を受けません。同じ変更は SPI_rollback() にも行われています。
</p>
<p>
PL/Python の修正も行われました。PL/Python では、このようなエラー処理が完全に省略されていて、Python 3.11 ではクラッシュすると報告されており、古いバージョンでは何も問題ないように見えますがメモリリークが起きます。
</p>
<li>パイプラインモードでの libpq のアイドル状態の処理が改善されました。  (&Aacute;lvaro Herrera, Kyotaro Horiguchi) (14)</li>
<p>
時々「WARNING:  message type 0x33 arrived from server while idle」が出る動作が報告されていました。また、PQgetResult() から問い合わせの最後の NULL の結果が失われる可能性がありました。
</p>
<li>ecpglib で予想外の順序の操作でのクラッシュが回避されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
EXEC SQL PREPARE などの特定の操作をデータベース接続を確立する前に呼び出すと、エラーを報告するのではなくクラッシュしました。
</p>
<li>ecpglib で冗長な newlocale() 呼び出しが回避されました。  (Noah Misch) (14)(13)(12)(11)(10)</li>
<p>
クエリごとにロケールオブジェクトを作成して解放するのではなく、最初の接続時にプロセスごとに C ロケールオブジェクトを割り当てるように修正されました。これにより、AIX における libc の メモリリークが軽減され、また、どのプラットフォームでも性能向上が見込まれます。
</p>
<li>psql の \watch コマンドで、Ctrl-C でキャンセルした後に改行をエコーするようになりました。  (Pavel Stehule) (14)(13)(12)(11)(10)</li>
<p>
これにより、libedit (およびおそらく libreadline) でカーソルがどの列にあるかについて混乱するのを防ぎます。
</p>
<pre>
（動作例）
db=# SELECT 1;
 ?column?
----------
        1
(1 row)

db=# \watch
2022年08月16日 07時53分10秒 (every 2s)

 ?column?
----------
        1
(1 row)

（修正前の動作）
^Cdb=#

（修正後の動作）
^C
db=#
</pre>
<li>pg_upgrade がアップグレード不可能な anyarray を取る関数を検出するように修正されました。  (Justin Pryzby) (14)</li>
<p>
バージョン 14 では、いくつかの組み込み関数が、anyarray ではなく anycompatiblearray 型を取るように変更されました。これはほとんど透過的ですが、これらの関数の上に構築されたユーザ定義の集約関数と演算子は、正確に一致する型で宣言する必要があります。古いシグネチャを参照するオブジェクトが存在すると、pg_upgrade が失敗する原因となるため、アップグレードを開始する前に、そのようなケースを検出して報告するように変更されました。
</p>
<pre>
(修正後の動作)
$ pg_upgrade -b /usr/local/pgsql-13.8/bin -B /usr/local/pgsql-14.5/bin \
    -d /usr/local/pgsql-13.8/data -D /usr/local/pgsql-14.5/data
Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for user-defined encoding conversions              ok
Checking for user-defined postfix operators                 ok
Checking for incompatible polymorphic functions             fatal

Your installation contains user-defined objects that refer to internal
polymorphic functions with arguments of type "anyarray" or "anyelement".
These user-defined objects must be dropped before upgrading and restored
afterwards, changing them to refer to the new corresponding functions with
arguments of type "anycompatiblearray" and "anycompatible".
A list of the problematic objects is in the file:
    incompatible_polymorphics.txt

Failure, exiting
$ cat incompatible_polymorphics.txt
In database: postgres
  aggregate: public.array_accum(anyelement)
</pre>
<li>pg_upgrade で --clone オプションを使用した場合に、clone() が失敗した後に誤った（OSからの）エラーメッセージが報告される可能性があり、修正されました。  (Justin Pryzby) (14)(13)(12)</li>
<li>contrib/pg_stat_statements が 32 ビットプラットフォームでの巨大な（数ギガバイトの）問い合わせ文字列ファイルでの整数オーバフローを回避するように修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
これに伴って、pg_stat_statements.max の最大値が 2147483647 から 1073741823 に変更されました。
</p>
<li>contrib/postgres_fdw で「WITH CHECK OPTION」制約がある場合に一括挿入を防止するようになりました。  (Etsuro Fujita) (14)</li>
<p>
外部テーブルのビューが WITH CHECK OPTION 制約を持つ場合、リモートで挿入されるデータを取得し、制約をチェックしますが、一度に複数の行が挿入されると、最初の 1行しかリモートのデータを取得できず、残りの行はローカルのデータで制約をチェックしていました。そのため、リモートのテーブルが行単位 BEFORE INSERT トリガをもち、リモートでデータが変更される場合、制約を適切にチェックできませんでした。
</p>
<pre>
db=# CREATE SERVER loopback
       FOREIGN DATA WRAPPER postgres_fdw OPTIONS (dbname 'db');
db=# CREATE USER MAPPING FOR CURRENT_USER SERVER loopback;
db=# CREATE FUNCTION row_before_insupd_trigfunc()
       RETURNS trigger LANGUAGE plpgsql AS $$
         BEGIN NEW.a := NEW.a + 10; RETURN NEW; END; $$;
db=# CREATE TABLE base_tbl (a int, b int);
db=# CREATE TRIGGER row_before_insupd_trigger
       BEFORE INSERT OR UPDATE ON base_tbl FOR EACH ROW
       EXECUTE PROCEDURE row_before_insupd_trigfunc();
db=# CREATE FOREIGN TABLE foreign_tbl (a int, b int)
       SERVER loopback OPTIONS (table_name 'base_tbl');
db=# CREATE VIEW rw_view AS
       SELECT * FROM foreign_tbl WHERE a &lt; b WITH CHECK OPTION;
db=# ALTER SERVER loopback OPTIONS (ADD batch_size '10');

（修正前の動作: Batch Size が 10 のまま、
  2行目の挿入が変更前データでチェックされ、制約違反のデータが格納される）
db=# EXPLAIN (VERBOSE, COSTS OFF) INSERT INTO rw_view VALUES (0, 15), (0, 5);
                                   QUERY PLAN
--------------------------------------------------------------------------------
 Insert on public.foreign_tbl
   Remote SQL: INSERT INTO public.base_tbl(a, b) VALUES ($1, $2) RETURNING a, b
   Batch Size: 10
   -&gt;  Values Scan on "*VALUES*"
         Output: "*VALUES*".column1, "*VALUES*".column2
 Query Identifier: -8082510435137086002
(6 rows)

db=# INSERT INTO rw_view VALUES (0, 15), (0, 5);
INSERT 0 2

（修正後の動作: Batch Size が 1 になり、
  2行目の挿入が変更後のデータでチェックされ、制約違反でエラーになる）
db=# EXPLAIN (VERBOSE, COSTS OFF) INSERT INTO rw_view VALUES (0, 15), (0, 5);
                                   QUERY PLAN
--------------------------------------------------------------------------------
 Insert on public.foreign_tbl
   Remote SQL: INSERT INTO public.base_tbl(a, b) VALUES ($1, $2) RETURNING a, b
   Batch Size: 1
   -&gt;  Values Scan on "*VALUES*"
         Output: "*VALUES*".column1, "*VALUES*".column2
 Query Identifier: 9094516644014608466
(6 rows)

db=# INSERT INTO rw_view VALUES (0, 15), (0, 5);
ERROR:  new row violates check option for view "rw_view"
DETAIL:  Failing row contains (10, 5).
</pre>
<li>contrib/postgres_fdw が非同期データフェッチクエリの送信失敗を検出するように修正されました。  (Fujii Masao) (14)</li>
<li>contrib/postgres_fdw が regconfig およびその他の reg* タイプの定数を適切なスキーマ pg_catalog 修飾で送信するようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<li>Linux で動的共有メモリの割り当て中にシグナルをブロックするようになりました。  (Thomas Munro) (14)(13)(12)(11)(10)</li>
<p>
これにより、シグナルが posix_fallocate() に割り込むときのバスエラー (SIGBUS) が回避されます。
</p>
<li>shm_open() からの予期しない「EEXIST」エラーを検出するようになりました。  (Thomas Munro) (14)(13)(12)(11)(10)</li>
<p>
これにより、Solaris で発生する可能性のあるクラッシュが回避されます。
</p>
<li>オープンソースの Unix 系 OS illumos では signalfd() を使用しないようになりました。  (Thomas Munro) (14)</li>
<p>
これにより、ハングアップやカーネルパニックが発生するように見えるため、修正が利用可能になるまでこの機能は使用されません。
</p>
<li>複合型に対するドメインを返す関数の結果を行全体の変数で参照する問い合わせ処理が修正されました。  (Tom Lane) (13)(12)(11)</li>
<pre>
（修正前のエラー動作例）
db=# CREATE TYPE ctyp4 AS (c1 boolean, c2 boolean);
db=# CREATE DOMAIN dom4 AS ctyp4 NOT NULL;
db=# CREATE FUNCTION f_ctyp4() RETURNS ctyp4 LANGUAGE sql
     AS $$ SELECT (true, true) $$;
db=# CREATE FUNCTION f_dom4() RETURNS dom4 LANGUAGE sql
     AS $$ SELECT (true, true) $$;

（複合型を返す場合は動作する）
db=# SELECT f_ctyp4 FROM f_ctyp4();
 f_ctyp4
------------------------
 (t,t)
(1 row)

（複合型のドメインを返す場合にエラーになっていた - 修正後は動作する）
db1=# SELECT f_dom4 FROM f_dom4();
ERROR:  type dom4 is not composite
</pre>
<li>プランナで GROUPING 関数で参照されている副問い合わせをプルアップする（上位の問い合わせに統合する）ときに、「ERROR: variable not found in subplan target list」が生じる問題が修正されました。  (Richard Guo) (13)(12)(11)(10)</li>
<pre>
（修正前バージョンでのエラー発生例）
db=# CREATE TABLE t5 AS SELECT generate_series(1, 100)::int i ;
db=# SELECT GROUPING(ss.x) FROM t5 CROSS JOIN LATERAL (
       SELECT (SELECT t5.i) as x) ss GROUP BY ss.x;
ERROR:  variable not found in subplan target list
</pre>
<li>pg_stat_get_subscription() 関数がゴミデータを含んだ追加の行を返す可能性があり、防止されました。  (Kuntal Ghosh) (13)(12)(11)(10)</li>
<p>
pg_stat_get_subscription() 関数は pg_stat_subscription ビューから使われます。
</p>
<li>XMLTABLE や JSON_TABLE に多すぎる列別名を付加した場合のクラッシュが回避されました。  (&Aacute;lvaro Herrera) (13)(12)(11)(10)</li>
<p>
そのような問い合わせに適切なエラーを返すようになりました。これまでは奇妙なエラーが出たり、クラッシュしたりしていました。
</p>
<pre>
（修正後の動作、f(v1,v2) で実際の列数より多く別名が指定されている）
db=# SELECT * FROM XMLTABLE (ROW () PASSING null COLUMNS v1 timestamp)
     AS f (v1, v2);
ERROR:  XMLTABLE function has 1 columns available but 2 columns specified

（修正前のエラーメッセージ）
ERROR:  no relation entry for relid 0
</pre>
<li>ビューやルールを（ダンプ出力や psql での表示のため）逆コンパイルする際、それが他で参照されうる場合には、SELECT 出力列の「AS "?column?"」別名句を見せるようになりました。  (Tom Lane) (13)(12)(11)(10)</li>
<p>
これまでは、自動生成されたこの別名は常に隠されていましたが、結果としてビューやルールがリストア不能になる稀なケースがありました。
</p>
<li>暗黙的に作成された演算子族がイベントトリガに通知されるようになりました。  (Masahiko Sawada) (13)(12)(11)(10)</li>
<p>
以前は、CREATE OPERATOR CLASS によって演算子族が暗黙的に作成された場合、イベントトリガに通知されませんでした。
</p>
<li>スタンバイサーバの昇格中にリスタートポイントが実行されている時に行われるコントロールファイルの更新が、修正されました。  (Kyotaro Horiguchi) (13)(12)(11)(10)</li>
<p>
以前は、リスタートポイント完了時にコントロールファイルの最終チェックポイントのフィールドが誤って更新される可能性があり、次の通常チェックポイント完了前にサーバがクラッシュした場合、PANIC が発生して再起動に失敗する可能性がありました。
</p>
<li>大規模トランザクションの論理レプリケーション中に、スタンバイの wal_receiver_timeout を発動させないようになりました。  (Wang Wei, Amit Kapila) (13)(12)(11)(10)</li>
<p>
以前は、プライマリサーバ上の大規模トランザクションが（おそらく変更されたテーブルがパブリッシュされていないために）スタンバイにデータを送信しない場合、スタンバイがタイムアウトする可能性がありました。キープアライブメッセージを定期的に送信することで修正されました。
</p>
<li>無効なタイムゾーン省略形ファイルを読み取る際のファイルクローズ漏れが防止されました。  (Kyotaro Horiguchi) (13)(12)(11)(10)</li>
<p>
このような場合には無害な警告メッセージが生じることがありました。
</p>
<li>カスタムサーバパラメータの短い説明に NULL を指定できるようになりました。  (Steve Chavez) (13)(12)(11)(10)</li>
<p>
短い説明は SHOW ALL の description などに表示されるもので、以前は、拡張でここに NULL を指定していると表示処理がクラッシュしていました。
</p>
<li>libpq で SSL 秘密鍵の誤った所有者チェックが削除されました。  (Tom Lane) (13)(12)(11)(10)</li>
<p>
以前のマイナーリリースで、サーバでの SSL 秘密鍵のアクセス権チェック方式を libpq にも適用しましたが、所有者チェックまで同様に行うべきではありませんでした。鍵ファイルにアクセス可能であるけれども所有者と異なるユーザでクライアントを実行するときに、予期せぬエラーが生じることがありました。
</p>
<pre>
(エラー例: root で root 以外のユーザが所有者の鍵ファイルを指定して psql を実行）
$ su -
# PGSSLCERT=/ssl/cert.pem PGSSLKEY=/ssl/key.pem PGSSLROOTCERT=/ssl/rcert.pem \
  PGSSLMODE=verify-ca psql -h localhost -U postgres -d postgres
psql: error: private key file "key.pem" must be owned by the current user or root
</pre>
<li>ecpg でサーバ接続が失われた場合のエラーを適切に報告するようになりました。  (Tom Lane) (13)(12)(11)(10)</li>
<p>
接続が失われた場合などに、libpq で生成されたエラー結果を誤って処理していたため、有用なエラーメッセージではなく「(null)」と出力されていました。また、古いリリースではクラッシュする可能性がありました
</p>
<li>PL/Perl のテストケースが Perl 5.36 で動作するように調整されました。  (Dagfinn Ilmari Mannsaker) (13)(12)(11)(10)</li>
<li>PostgreSQL ビルド中に複数の OpenLDAP がインストールされている場合に、古い libldap_r ライブラリを誤って使用しないように configure が修正されました。  (Tom Lane) (13)(12)(11)(10)</li>
<li>論理レプリケーションでマテリアライズドビューのヒープ書き換え一時テーブルを無視するようになりました。  (Euler Taveira) (10)</li>
<p>
「FOR ALL TABLES」指定のパブリケーションは、個別にテーブルを指定せず、全テーブルが複製対象となり、一時テーブルを複製しようとします。DDL 中のヒープ書き換え一時テーブルは除外されますが、マテリアライズドビューの書き換え中に作成された内部一時テーブルをカバーできませんでした。これにより、REFRESH MATERIALIZED VIEW 中に「logical replication target relation ... does not exist」というエラーが発生するリスクがありました。
</p>
</ol>

<div>
<a href="https://www.sraoss.co.jp/prod_serv/support/pgsql-mainte/?utm_source=sraoss-techblog&utm_medium=referral&utm_campaign=under-article-pgsql" rel="noopener" style="color:initial;" target="_blank" class="no-ext"></p>
<div style="background-color:#DAEFF6; padding:20px; border-radius:8px; text-align:center;">
SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。<br />
詳しくは<strong style="color:#2581c4;">弊社ホームページ</strong>をご覧ください。
</div>
<p></a>
</div>

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 11.16 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-16/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Fri, 03 Jun 2022 00:39:13 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.15]]></category>
		<category><![CDATA[PostgreSQL 11.16]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=10129</guid>

					<description><![CDATA[このリリースは 11.15 からの修正リリース（2022年5月12日リリース）です。 11.X からのアップデートではダンプ、リストアは不要です。 また、11.14 よりも前のバージョンからアップデートする場合には、11 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 11.15 からの修正リリース（2022年5月12日リリース）です。<br />
11.X からのアップデートではダンプ、リストアは不要です。<br />
また、11.14 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/11-14/ ">11.14 のリリース情報</a>も参照してください。</p>
<p><span id="more-10129"></span></p>
<h3>PostgreSQL 11.15 から 11.16 への変更点</h3>
<p>14.3、13.7、12.11、11.16、10.21 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>「セキュリティ限定された操作」のサンドボックス内では追加操作を制限するようにしました。  (Sergey Shinderuk, Noah Misch) (14)(13)(12)(11)(10)</li>
<p>
自動VACUUM、CLUSTER、CREATE INDEX、REINDEX、REFRESH MATERIALIZED VIEW、pg_amcheck では「セキュリティ限定された操作」による保護が有効化されるのが遅すぎたり、全く働かなかったりしていました。
</p>
<p>
データベース内に永続オブジェクトを作成する権限を持ったユーザは、スーパーユーザ権限で任意の SQLコードを実行するオブジェクトを定義できました。仕込まれた SQLコードは、次に自動VACUUM が行われるときに、あるいは、スーパーユーザがそのオブジェクトに作用するいずれかのコマンドを実行したときに、実行されます。
</p>
<p>
本脆弱性は CVE-2022-1552 として登録されています。
</p>
<li>gist_ltree_ops のインデックスについて、デフォルトのシグネチャ長が修正されました。  (Tomas Vondra, Alexander Korotkov) (14)(13)</li>
<p>
ltree拡張を演算子クラスパラメータをサポートするようにアップグレードするときに、ltree列に対する GiSTインデックスのデフォルトのシグネチャ長（ハッシュサイズ）が、意図せず変更されてしまいました。最初から ltree をバージョン 1.2 にアップグレードしている場合を除き、このようなインデックスに何らか操作が行われた場合、シグネチャ長が 8バイトではなく 28バイトと見做されて動作します。したがって、おそらくそのインデックスは壊れています。安全のためバージョンアップ後に全ての ltree の列に対する GiSTインデックスを再作成（REINDEX）することを推奨します。なお、ltree[] 配列の列に対する GiSTインデックスには影響しません。
</p>
<li>素のテーブルを参照する行全体の値の列に対して、問い合わせで指定された列の別名を使わないようにしました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
選択リストの最上位以外での tbl.*などの行全体変数から作られたタプルの列名は、今後は、もしあるなら常に関連して名前付けされた複合型の要素名になります。これまでは FROM のエントリに適用された全ての列の別名を追跡させるように試みていました。しかし、これは意味がないと判断されました。
</p>
<p>
従来実装では、行全体をあらわす列を使用したテーブルを作った後、行全体の列の元となるテーブルの列名を付け直した場合に、そのようなテーブルのSELECT で予期せぬエラーが発生して、格納したデータが読めなくなってしまうことがありました。
</p>
<pre>
（報告された障害発生ケース）
db=# CREATE TABLE t3 (data int);
db=# CREATE VIEW v3 AS SELECT t3 FROM t3;
db=# CREATE TABLE t3_log (ts timestamp, what v3);

（列名を付け直す操作）
db=# ALTER TABLE t3 ADD big_data bigint;
db=# UPDATE t3 SET big_data = data;
db=# UPDATE t3_log SET what.t3.big_data = (what).t3.data;
db=# ALTER TABLE t3 DROP data;
db=# ALTER TABLE t3 RENAME big_data TO data;
db=# INSERT INTO t3 VALUES (123456);
db=# INSERT INTO t3_log SELECT now(), v3 FROM v3;

（この時は正しく出力）
db=# SELECT * FROM t3_log;
             ts             |     what
----------------------------+--------------
 2022-05-16 13:49:54.862458 | ("(123456)")
(1 row)
db=# \c

（接続し直した後にはエラーになる）
db=# SELECT * FROM t3_log;
ERROR:  record type has not been registered
</pre>
<p>
列名を付け直したい場合の本障害の回避策は、副問い合わせの階層を追加して、行全体の変数が副問い合わせの出力を参照して、素のテーブルを参照しないようにすることです。これは上記のエラー発生例で言えば「CREATE VIEW ...」を「CREATE VIEW v3 AS SELECT v::t3 AS t3 FROM (SELECT * FROM t3) v(d);」と記述することです。
</p>
<li>interval型からエポック値を抽出するときの誤った丸めが修正されました。  (Peter Eisentraut) (14)</li>
<p>
numeric型を返すようになった新しい EXTRACT の実装コードで、誤って DAYS_PER_YEAR 定数を整数型に変換して切り捨てていたため、13.x バージョン以前の float型を返すコードと戻り値が異なっていました。
</p>
<li>pg_stat_get_replication_slot(NULL) 実行時のクラッシュが防止されました。  (Andres Freund) (14)</li>
<p>
この関数はカタログデータで STRICT と定義されるべきでしたが、バージョン14 ではこれが指定されていなかったため、代替策として、関数実装に実行時のチェックが追加されました。
</p>
<li>table_to_xmlschema() などの XML関数における timestamptz型、timetz型の誤った出力が修正されました。  (Renan Soares Lopes) (14)(13)(12)(11)(10)</li>
<p>
これらのデータ型に対する XMLスキーマ出力では文字列パターンの正規表現が壊れていました。
</p>
<li>列数がゼロの「VALUES」句のパーサ処理のクラッシュが回避されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<pre>
（報告された障害発生ケース）
db=# CREATE TEMP TABLE nocols();
db=# INSERT INTO nocols DEFAULT VALUES;
db=# SELECT * FROM nocols n, LATERAL (VALUES(n.*)) v;
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.
</pre>
<li>プランノードの Result が Append ノードのすぐ下にあらわれる場合のプランナのエラーやクラッシュが修正されました。  (Etsuro Fujita) (14)</li>
<p>
非同期リモートクエリをサポートするために最近追加されたコードは、このケースを処理できず、クラッシュや「ERROR:  unrecognized node type ..」などの認識されないノードタイプに関するエラーが引き起こされました。
</p>
<li>「SEARCH」句または「CYCLE」句を使用するクエリに重複するテーブル式の名前が含まれている場合のプランナのエラーやクラッシュが修正されました。  (Tom Lane, Kyotaro Horiguchi) (14)</li>
<p>
再帰的な WITH クエリの名前が自身の中で再利用されると、プランナがクラッシュしたり、奇妙なエラーを報告したりする可能性がありました。
</p>
<pre>
（障害発生例）
db=# WITH RECURSIVE x(col) as (
       SELECT 1 UNION (
	     WITH x AS (SELECT * FROM x)
           SELECT * FROM x)
     ) SEARCH DEPTH FIRST BY col SET seq
     SELECT * FROM x;
ERROR:  could not find attribute 2 in subquery targetlist
</pre>
<li>外側のクエリ階層を参照する GROUPING() 構文のプランナエラーが修正されました。  (Richard Guo, Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
奇妙なエラーやアサート失敗が報告されました。
</p>
<pre>
（エラー発生例）
db=# SELECT (SELECT GROUPING(v1)) FROM (VALUES ((SELECT 1))) v(v1) GROUP BY v1;
ERROR:  plan should not reference subplan's variable
</pre>
<li>返却可能な列と返却不可能な列の両方を持つインデックスに対するインデックスオンリースキャンのプラン生成が修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
以前のコーディングでは、返却可能な列に加え、返却不可能な列も読み取ろうとする可能性がありました。 これは実際には無効な値に対して何も行わなかったためおよそ無害でしたが、最近追加されたエラーチェックでそのようなプランを拒否して、下記のエラーメッセージを出していました。
</p>
<pre>
ERROR:  XX000: variable not found in subplan target list
</pre>
<li>EvalPlanQual の実行中に古いタプルをロックしようとする際に、ピン(PIN)で固定されなくなった共有バッファにアクセスしないようになりました。  (Tom Lane) (14)(13)(12)</li>
<p>
EvalPlanQual は READ COMMITTED 隔離レベルの問い合わせにおける内部的な処理です。
</p>
<p>
従来コードはピンを解放した後、さらに数回バッファにアクセスしていました。理論的には別プロセスがピンがなくなった時点ですぐにバッファを再利用し（あるいは、より可能性が高いのは、その空き領域をデフラグしようとし）、タプルの新しいバージョンを見つけるのに失敗する可能性があります。
</p>
<li>再並べ替えを実行している IndexScanノードでの、クエリ存続期間におけるメモリリークが修正されました。  (Aliaksandr Kalenik) (14)(13)(12)(11)(10)</li>
<li>関数の並列性属性と「SET」変数リストを同じコマンドで変更できるように ALTER FUNCTION が修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
一つの ALTER FUNCTION コマンドで関数の「SET」句も更新した場合、並列性属性の変更が失われていました。
</p>
<pre>
（誤動作例／「PARALLEL safe」を指定したので proparallel は 「s」が正しい）
db=# CREATE FUNCTION public.f14() RETURNS int LANGUAGE sql AS 'SELECT 1';
db=# ALTER FUNCTION public.f14() SET timezone TO 'UTC' PARALLEL safe;
db=# SELECT proname, proparallel, proconfig FROM pg_proc WHERE proname = 'f14';
 proname | proparallel |   proconfig
---------+-------------+----------------
 f14     | u           | {TimeZone=UTC}
(1 row)
</pre>
</p>
<li>制約に「所有されている」インデックスの検出が厳格化されました。  (Tom Lane, Japin Li) (14)</li>
<p>
一部のコードパスで、外部キー制約が依存しているインデックスを、ユニーク制約または主キー制約によって所有されているインデックスと取り違えていました。その結果、外部キー制約を持つテーブルに対する特定の ALTER TABLE 操作に際して、下記のような奇妙なエラーが発生していました。
</p>
<pre>
 ERROR:  relation 145678 has multiple clustered indexes 
または
 ERROR:  "t15_pkey" is not an index for table "t15" 
</pre>
<li>ALTER TABLE でテーブルのシステム列を変更しようとすると、間違ったエラーが発生する問題が修正されました。  (Tom Lane) (14)(13)(12)</li>
<p>
システムは「ERROR:  cannot alter system column "cmax"」などと、それができないことを通知するべきですが、代わりに「ERROR:  no owned sequence found」を報告する場合がありました。
</p>
<li>先頭キーが式であるインデックスを使用して CLUSTER 処理を行った場合に、テーブルの行が誤った並べ替えになる問題が修正されました。  (Peter Geoghegan, Thomas Munro) (14)(13)(12)(11)(10)</li>
<p>
テーブルは正しいデータで再構築されますが、インデックスの順序とはほとんど関係のない順序になりました。
</p>
<li>ソートされた GiSTインデックスのビルド直後にシステムクラッシュが発生した場合のデータ損失が防止されました。  (Heikki Linnakangas) (14)</li>
<p>
ソートを使用して GiSTインデックスを構築するコードパスは、完了時にファイルの fsync を怠っていました。このため、その後すぐにオペレーティングシステムがクラッシュした場合、インデックスが破損する可能性がありました。
</p>
<li>パーティション化されたインデックスを削除する際にデッドロックエラーのリスクがあり、修正されました。  (Jimmy Yih, Gaurab Dey, Tom Lane) (14)(13)(12)(11)</li>
<p>
必要なテーブルとインデックスのロックが確実に標準的な順序（子の前に親、インデックスの前にテーブル）で取られるようになりました。DROP INDEX の以前のコーディングでは、これとは異なる方法でロックを取っていたため、標準的な順序でこれらのロックを取る同時実行の問い合わせに対してデッドロックが発生する可能性がありました。
</p>
<li>DROP TABLESPACE とチェックポイントの間の競合状態が修正されました。  (Nathan Bossart) (14)(13)(12)(11)(10)</li>
<p>
DROP TABLESPACE によって強制されるチェックポイントが、テーブルスペースのディレクトリからすべてのデッドファイルを削除することに失敗して、以下のような偽のエラーが発生する場合がありました。
</p>
<pre>
ERROR:  tablespace "tblspc20" is not empty
</pre>
<li>チェックポイント実行と並行して TRUNCATEコマンドを実行した後に、クラッシュリカバリが失敗する可能性があり、修正されました。  (Kyotaro Horiguchi, Heikki Linnakangas, Robert Haas) (14)(13)(12)(11)(10)</li>
<p>
チェックポイントが完了できるようになる前に、テーブルのディスクファイルが全削除されることをTRUNCATE は保証しなければなりません。そうでないと、そのチェックポイントから開始したリプレイが、削除されているはずのページの予期せぬデータを見つけて、リプレイ失敗を引き起こすおそれがありました。
</p>
<li>一時オブジェクト削除中における安全でないTOASTデータアクセスが修正されました。  (Andres Freund) (14)(13)(12)(11)(10)</li>
<p>
サーバプロセス終了時に「FATAL: cannot fetch toast data without an active snapshot」のエラーを出して、一時オブジェクトの削除に失敗することがありました。次に一時スキーマを使う際に正常にクリーンアップされるため、通常は無害です。
</p>
<li>カスタム設定名の最初の文字に「_」が再度使えるようになりました。  (Japin Li) (14)</li>
<p>
バージョン14 ではそのような名前が意図せず使えなくなってしまっていました。
</p>
<li>compute_query_id 設定に指定可能な値として「regress」が追加されました。  (Michael Paquier) (14)</li>
<p>
これはリグレッションテストを容易にすることを目的としており、クエリID が計算されるけれども EXPLAIN の出力には表示されません。
</p>
<li>RegisterSyncRequest の待機ロジックが改善されました。  (Thomas Munro) (14)(13)(12)</li>
<p>
RegisterSyncRequest は局所的にストレージ同期の要求を受け付けたり、要求を checkpointerプロセスに転送したりする、内部実装関数です。
</p>
<p>
その中で checkpointer への同期要求キューが溢れた場合（shared_buffers が小さい場合に起こりえます）、その待ち行列が減るのを待つ動作をします。このときの待機を示す待機イベント「RegisterSyncRequest」が追加されました。
</p>
<li>書き込みと書き込みの間で checkpointerプロセスが待機しているときにはラッチイベントを起こすようになりました。  (Thomas Munro) (14)</li>
<p>
これは同期リクエストを送信するバックエンドの反応性を改善します。更にこの待機に対応した待機イベント「CheckpointerWriteDelay」も追加されました。
</p>
<li>WAL の後続レコードが欠けている時にスタンバイを昇格すると「PANIC: xlog flush request is not satisfied」が発生する問題が修正されました。  (Sami Imseih) (14)(13)(12)(11)(10)</li>
<li>ホットスタンバイのコンフリクトを処理する際に自己デッドロックが起きる可能性があり、修正されました。  (Andres Freund) (14)(13)(12)(11)(10)</li>
<p>
不運なタイミングのとき、WAL を適用するプロセスが他プロセスのバッファロックの解放を待って、動作が止まってしまう可能性がありました。
</p>
<li>ロジカルレプリケーションの変更を送信する際、パーティションの先祖関係を間違ってしまう可能性があり、修正されました。  (Tomas Vondra, Hou zj, Amit Kapila) (14)(13)</li>
<p>
publish_via_partition_root オプションが true に指定されていて、更新するリレーションに対する異なる先祖で指定された複数のパブリケーションがある場合（即ち親子関係にあるリレーション各々にパブリケーションを作っている場合）、サブスクリプションへの変更の報告に際して間違った先祖リレーションを選択することがありました。
</p>
<li>max_sync_workers_per_subscription 設定の制限に抵触する場合でもロジカルレプリケーションの apply workerプロセスが再起動されるようになりました。  (Amit Kapila) (14)(13)(12)(11)(10)</li>
<p>
本設定に対する上限検査コードの欠陥により、これまでは再起動されたワーカを直ぐに終了してしまっていて、ほとんどのワーカが存続できませんでした。
</p>
<li>UPDATE に対して、変更されていないレプリカアイデンティティ（REPLICA IDENTITY）のキー列を、それが外部TOAST格納されている場合には WALログに含めるようになりました。  (Dilip Kumar, Amit Kapila) (14)(13)(12)(11)(10)</li>
<p>
この対処をしないと、サブスクライバはその値を見ることができないので、更新を正しく複製できないことになります。
</p>
<li>psコマンドにおけるサーバプロセス表示の置き換えに対応していないプラットフォームを適切に処理できるようになりました。  (Andrew Dunstan) (14)(13)</li>
<p>
このようなプラットフォームはほとんどありません。そのため、これまでリファクタリングが潜在的なメモリ破壊をもたらすことに気づかれませんでした。サポートされているプラットフォームで該当する唯一のものは Cygwin で、バックエンドプロセスのクラッシュが報告されました。
</p>
<li>タイマ割り込みの見逃しに対して、より頑健になりました。  (Michael Harris, Tom Lane) (14)</li>
<p>
バージョン14 で追加された最適化は、なんらかの理由でサーバプロセスがタイマ割り込みを逃してしまった場合は他についてもカーネルに要求を繰り返さないというもので、セッションの以降においてタイムアウト検出に失敗することになりました。
</p>
<p>
これでは脆弱すぎると判断され、リカバリパスが追加されました。
</p>
<li>PL/Perl関数のコンパイル時には SPI関数は実行できないようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
PL/Perl関数のコンパイル時には Perl はユーザ定義コードを実行すると考えられます。しかしながら、SPI 経由の SQL操作を行うコードは望ましくなく、クラッシュかセキュリティ障害を起こす可能性がありました。関数の検証に際して本当にコード実行をしたいわけではありません。そこで、代わりに親切なエラーメッセージを出す検査が加えられました。
</p>
<li>libpq が root所有の SSL秘密鍵ファイルを受け入れるようになりました。  (David Steele) (14)(13)(12)(11)(10)</li>
<p>
この変更により、libpq の SSL鍵ファイルの所有者とアクセス許可の安全チェックが、バージョン9.6 以降のサーバと統一されます。すなわち、現在のルールに加え、鍵ファイルの所有者が root であって、パーミッションが 0640 以下の場合を許容するようになりました。これは、鍵ファイルのシステム全体での管理に役立ちます。
</p>
<li>libpq の PQisBusy()関数の接続エラー後の動作が修正されました。  (Tom Lane) (14)(13)(12)</li>
<p>
書き込みエラーを検出した場合、PQisBusy() は常に真を返しましたが、これは誤りでした。サーバから何か読み取れるまで、通常は入力処理を継続したいところでした。
</p>
<p>
この障害の実際の影響は、libpq の非同期クエリAPI を使用するアプリケーションが、PQconsumeInput() が致命的なエラーを返した場合にしか接続断を検出しないことです。この修正により、接続断が順当にエラーの PGresult オブジェクトを介して報告されるようになりました。これはほとんどのアプリケーションにとって相応しい動作です。
</p>
<li>psql、pg_dump、および pg_amcheck で「データベース.スキーマ.テーブル」という構文を再度許容するようになりました  (Mark Dilger) (14)</li>
<p>
14 より前のバージョンは、2つ以上の「.」を含むパターンにおけるスキーマとテーブル以外の全ての修飾名を黙って無視していました。バージョン14 でのリファクタリングの誤りで、そのユースケースがエラーになるようになってしまいました。本バージョンで復活しましたが、先頭の修飾名がカレントデータベースの名前と一致しない場合にはエラーが発生します。
</p>
<pre>
（バージョン 14.2 で以下エラー／13.x 以前と 14.3 以降では実行可能）
db1=# \d db1.public.t1
Did not find any relation named "db1.public.t1".

（バージョン14.3 で以下エラー／13.x 以前では実行可能）
db1=# \d foo.bar.public.t1
improper qualified name (too many dotted names): foo.bar.public.t1
</pre>
<li>pg_ctl は、stop/restart/promote の動作を待機している間、postmasterプロセスが動作していることを再チェックするようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
pg_ctl は、stop または promote シグナルを送信する一方で postmasterプロセスが動作していること（PID が有効であるか）を 1回確認しますが、その後は単純に PIDファイルが削除されるまで待機していました。postmaster が PIDファイルを削除したり、制御ファイルを更新したりせず、非正常に終了した場合、pg_ctl はタイムアウトになるまで待機していました。
</p>
<p>
これに替えて postmasterプロセスがまだ存在しているかをときどき再チェックするようになりました。
</p>
<li>pg_waldump のエラー処理が修正されました。  (Kyotaro Horiguchi, Andres Freund) (14)(13)(12)(11)</li>
<p>
WALセグメントサイズを知るために WALファイルを読み取ったとき、ファイルサイズが XLOG_BLCKSZ よりも小さい場合（例えば 0バイト）、pg_waldump は誤ったエラー報告をしていました。また、このエラーメッセージおよび関連するエラーメッセージで報告されるファイル名は無効である可能性がありました。
</p>
<pre>
（報告された誤ったメッセージ／正しくないファイル名や要因が示される）
pg_waldump: fatal: could not read file ".....": .....
</pre>
<li>contrib/pageinspect の関数が全てゼロのページに対応するようになりました。  (Michael Paquier) (14)(13)(12)(11)(10)</li>
<p>
これは正当な境界条件的ケースでしたが、このモジュールではほぼ想定されていませんでした。必要に応じて、NULL を返すか、行を返さないように変更されました。これは、エラーを発生させるよりも有効です。
</p>
<li>contrib/pageinspect で、破損したページの「特別な領域」に対する保護を追加し、正しいページサイズのチェックを強化し、不足していたインデックスの型チェックが追加されました。  (Michael Paquier, Justin Pryzby, Julien Rouhaud) (14)(13)(12)(11)(10)</li>
<p>
これらの変更により、モジュールが不良データでクラッシュする可能性が低くなりました。
</p>
<li>contrib/postgres_fdw で BEFORE INSERT ... FOR EACH ROW トリガが外部テーブルに存在する場合、バッチ挿入が無効にされました。  (Etsuro Fujita) (14)</li>
<p>
このようなトリガはテーブルを照会する際、手前で挿入した行を参照するかもしれません。バッチ挿入では、これらの行がまだ可視となってない可能性があるため、予期せぬ動作を回避するため、無効にされました。
</p>
<li>contrib/postgres_fdw で、リモートで順序付けされたクエリを要求する前にORDER BY句が安全に渡せることを検証し、必要に応じて USING句を含めるようになりました。  (Ronan Dunklau) (14)(13)(12)(11)(10)</li>
<p>
この修正はリモートサーバが意図と異なる順序で並べ替えるケースを防止します。これは見た目だけの場合もありますが、リモートデータがローカルで実行されるマージ結合の入力として使用されると、完全に間違った結果が生じる可能性がありました。
</p>
<li>sys/epoll.h があり、sys/signalfd.h はないプラットフォームを扱えるようにconfigure が修正されました。  (Tom Lane) (14)</li>
<li>LLVM 14 で動作するように JITコードが更新されました。  (Thomas Munro) (14)(13)(12)(11)</li>
<li>clang の -fsanitize=undefined オプションで様々な障害をクリーンアップするようになりました。  (Tom Lane, Andres Freund, Zhihong Yu) (14)(13)(12)(11)(10)</li>
<p>
これらの変更のほとんどは、C および POSIX 標準の文書に型通りに準拠するためのものであり、本番ビルドに影響を与える可能性はほとんどありません。
</p>
<li>OpenSSL なしでビルドする場合は、libpq の pkg-config ファイルに OpenSSL の依存関係を追加しないように修正されました。  (Fabrice Fontaine) (14)</li>
<li>式の中にネストされたステートメントをサポートしない CコンパイラでビルドできるようにPL/Perl が修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<li>Windows でビルドに MSVC を使用していない場合に、pg_dumpall のビルドエラーが発生する可能性があり、修正されました。  (Andres Freund) (14)(13)(12)(11)(10)</li>
<p>
mingw の gcc によるビルドで問題が報告されました。
</p>
<li>Windowsビルドでは、pexports の代わりに gendef を使用してDEFファイルを作るようになりました。  (Andrew Dunstan) (14)(13)(12)(11)(10)</li>
<p>
これにより、ビルドプロセスが最新の MSys ツールチェーンで機能するように調整されました。
</p>
<li>MinGW でビルドされたプログラムでの余分なワイルドカードパターンの展開が防止されました。  (Andrew Dunstan) (14)(13)(12)(11)(10)</li>
<p>
何らかの理由で、MinGW によって提供される Cライブラリは、デフォルトでプログラムのコマンドライン引数のシェルワイルドカード文字を展開してしまいます。MSVC では特に発生しないため、これは混乱を招くのでパターン展開が無効化されました。
</p>
<li>タイムゾーンデータファイルが tzdata release 2022a に更新されました。パレスチナでの夏時間法の変更に加えて、チリ、ウクライナの歴史的修正が含まれます。   (14)(13)(12)(11)(10)</li>
<li>論理レプリケーションのサブスクライバにおける、サポートされていないテーブル種別に対するエラーメッセージが改善されました。  (Tom Lane) (12)(11)(10)</li>
<p>
バージョン13 以降のサーバは、パーティションテーブルのパブリッシュがサポートされるようになりました。バージョン13 より古いバージョンのサーバは、パーティションテーブルのサブスクライブを処理できず、「table ... not found on publisher」のような誤解を招くエラーメッセージを表示していましたが、より的確なメッセージを表示するように修正されました。
</p>
</ol>

<div>
<a href="https://www.sraoss.co.jp/prod_serv/support/pgsql-mainte/?utm_source=sraoss-techblog&utm_medium=referral&utm_campaign=under-article-pgsql" rel="noopener" style="color:initial;" target="_blank" class="no-ext"></p>
<div style="background-color:#DAEFF6; padding:20px; border-radius:8px; text-align:center;">
SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。<br />
詳しくは<strong style="color:#2581c4;">弊社ホームページ</strong>をご覧ください。
</div>
<p></a>
</div>

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 11.15 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-15/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Thu, 17 Mar 2022 05:58:32 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.14]]></category>
		<category><![CDATA[PostgreSQL 11.15]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=9404</guid>

					<description><![CDATA[このリリースは 11.14 からの修正リリース（2022年2月10日リリース）です。 11.X からのアップデートではダンプ、リストアは不要です。 しかしながら、本リリースで修正されたいくつかの障害により既にインデックス ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 11.14 からの修正リリース（2022年2月10日リリース）です。<br />
11.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、本リリースで修正されたいくつかの障害により既にインデックスに破損が生じている可能性があるため、該当するインデックスを再構築することが推奨されます。<br />
また、11.14 よりも前のバージョンから移行する場合には <a href="/tech-blog/pgsql/11-14">11.14 のリリース情報</a>も確認してください。</p>
<p><span id="more-9404"></span></p>
<h3>PostgreSQL 11.14 から 11.15 への変更点</h3>
<p>14.2、13.6、12.10、11.15、10.20 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>REINDEX CONCURRENTLY の問題を防止するため、TOAST テーブルの更新に標準のロックプロトコルが適用されました。  (Michael Paquier) (14)(13)(12)</li>
<p>
REINDEX CONCURRENTLY を TOASTテーブルまたは TOASTテーブルのインデックスに 適用した場合、破損したインデックスを生成することがよくありました。これは TOASTエントリを更新するセッションが、他の更新の動作と同様にトランザクションがコミットされるまで ROW EXCLUSIVE ロックを保持するのではなく、ROW EXCLUSIVE ロックをすぐに解放したために発生しました。今回 TOAST 更新が通常のルールに従ってテーブルロックを保持するよう修正されました。既存の破損したインデックスは、再度 REINDEX を実行することで修復できます。
</p>
<li>ページプルーニング中に RECENTLY_DEAD タプルが状態を完全に DEAD に変更した時の HOTチェーンの破損が修正されました。  (Andres Freund) (14)</li>
<p>
VACUUM では、それを指すリダイレクトアイテムが残っている状態で RECENTLY_DEAD のタプルを削除することがありえました。そのようなタプルのアイテムスロットが後に新しいタプルで再利用されると、既存の HOTチェーンの一部とみなされ、インデックス破損が形成されます。
</p>
<p>
発生した場合はテーブルのインデックス再作成で修復できます。しかし、これは非常に確率の低いシナリオであるため、発生したかもしれないという可能性だけでインデックスを再作成することは推奨されません。
</p>
<li>ローカルパーミッションと外部パーティションが混在するテーブルのEvalPlanQual再チェックでのクラッシュが修正されました。  (Etsuro Fujita) (14)</li>
<p>
EvalPlanQual再チェックは READ COMMITTED 隔離レベルの問い合わせで使われる処理です。
</p>
<li>COPY TO でのメモリ処理の誤りが修正されました。  (Bharath Rupireddy) (14)</li>
<p>
この見落としにより、COPY でエラーが発生した後、誤ったエラーメッセージやクラッシュが発生することがありました。
</p>
<li>同時に DROP STATISTICS で統計オブジェクトが削除された時に発生する ALTER STATISTICS での NULLポインタ参照によるクラッシュが回避されました。  (Tomas Vondra) (14)(13)</li>
<li>マルチ範囲型データから範囲を抽出する際に、アライメントのパディングが正しく処理されるようになりました。  (Alexander Korotkov) (14)</li>
<p>
この誤りは可変長データ型のマルチ範囲を処理する際にクラッシュを引き起こす可能性がありました。
</p>
<li>無名 RECORD データ型に対するハッシュの過度な楽観的使用が修正されました。  (Tom Lane) (14)</li>
<p>
これにより、「ERROR:  could not identify a hash function for type record」（型レコードのハッシュ関数を識別できない）のエラーが防止されます。
</p>
<li>パラレルで単一の子ノードを持つ Appendノードに対する誤ったプラン作成が修正されました。  (David Rowley) (14)(13)(12)</li>
<p>
場合によっては、Append が単純化されるべきではない時に単純化され、誤った問い合わせ結果（重複した行）が発生することがありました。
</p>
<p>
単一の子ノードを持つ Appendノードは、例えば「SELECT id, c FROM t1 UNION ALL SELECT id, c FROM t2 WHERE false」といった形を持つ問い合わせのプランで出現する可能性がありました。
</p>
<li>インデックスに返却不能の列が含まれる場合について、インデックスオンリースキャンプランが修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
インデックスの列にはインデックスオンリースキャンで返すことができるか（返却可能列か返却不能列か）を示す、returnable属性があります。
</p>
<p>
インデックスが返却可能列と返却不能列の両方を持ち、返却不能列の 1つが返却可能列にあらわれるテーブル列を使用した式である場合、その式を使用した問い合わせは、返却可能列から式を再計算するのではなく、返却不能列を読もうとするインデックスオンリースキャンプランとなる可能性がありました。返却不能列は NULL として読み込まれるため、誤った問い合わせ結果が発生しました。
</p>
<pre>
（障害動作例／ここでの lower(c) は返却不能列）
db=# CREATE TABLE t9 (c text);
db=# INSERT INTO t9 VALUES (md5('A')), (md5('B'));
db=# CREATE INDEX ON t9 USING gist(lower(c) gist_trgm_ops) INCLUDE (c);
db=# SET enable_seqscan TO off;
db=# \pset null *NULL*
db=# SELECT lower(c), c FROM t9;
 lower  |                c
--------+----------------------------------
 *NULL* | 7fc56270e7a70fa81a5935b72eacbe29
 *NULL* | 9d5ed678fe57bcca610140957afab571
(2 rows)
</pre>
<li>Memoize の上位からきたパラメータを使用するサブプランを処理できるように、Memoizeプランノードが修正されました。  (David Rowley) (14)</li>
<p>
この障害により誤った問い合わせ結果が生じるケースが報告されました。
</p>
<li>Memoizeプランノードがハッシュ不可能な結合の演算子で正しく動作するように修正されました。  (David Rowley) (14)</li>
<p>
結合条件に不等号を使っている場合や浮動小数点データ型で 0.0 と -0.0 がある場合などで問題が生じました。この障害により、クラッシュや誤った問い合わせ結果が生じる可能性があります。
</p>
<li>指定されていない型修飾へのキャストにより、長さの強制関数の呼び出しではなく、RelabelTypeノードが生成されるようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
強制関数は正しい動作（何もしないこと）を実行しますが、この変換は非効率で望ましくありません。
</p>
<p>
character(N) 型を bpchar 型にキャストする場合が該当します。
</p>
<li>anycompatible で始まる名前の疑似データ型（以下「anicompatible*」と記載）について一致判定が修正されました。  (Tom Lane) (14)(13)</li>
<p>
anicompatible* 型の多相パラメータを持つ関数や演算子が、実際には本当は一致しないはずの引数の集合に一致したと、パーサが誤判断することがありました。
</p>
<p>
報告されたケースでは、一つの呼び出しに複数の演算子を一致させることになり、「ERROR:  operator is not unique: ...」「HINT:  Could not choose a best candidate operator. You might need to add explicit type casts.」などのあいまいな演算子だというエラーを引き起こしました。一方、より後の処理段階でエラーを起こすこともあり得ました。
</p>
<li>ちょうど WALページの境界でデータベースが整合性を持つ状態に到達した場合の、WALリプレイ失敗が修正されました。  (&Aacute;lvaro Herrera) (14)(13)(12)(11)(10)</li>
<p>
修正されませんが、これは 9.6.x でも該当します。
</p>
<li>物理ストリーミングレプリケーションのスタンバイサーバの startup処理がトランザクションID 周回を許容するように修正されました。  (Abhijit Menon-Sen, Tomas Vondra) (14)(13)(12)(11)(10)</li>
<p>
プライマリ上のアクティブなトランザクションのセットが周回境界を越えている間にスタンバイサーバが起動すると（古いトランザクションよりも小さい XID を持つ新しいトランザクションがいくつか存在するため）、「ERROR: out-of-order XID insertion in KnownAssignedXids」エラーが生じました。再試行されますがこのエラーを乗り越えることはできません。
</p>
<li>ロジカルレプリケーションで子テーブルのデータの二重送信が回避されるようになりました。  (Hou Zhijie) (14)(13)</li>
<p>
パブリケーションに子テーブルと親テーブルの両方が含まれ、publish_via_partition_root オプションが設定されている場合、サブスクライバは子テーブルと親テーブルの両方で無駄な同期を開始していました。このような場合は親テーブルのみが同期されるようになりました。
</p>
<li>ロジカルレプリケーション接続で発行される SQLコマンドの字句制限が撤廃されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
これまでは、引用符で囲まれていないセミコロンを含む SQLコマンド、奇数の一重引用符または二重引用符を含むドル引用符で囲まれたリテラル、または SQLコマンドがコメントで始まる場合、walsenderプロセスがエラーを起こしました。
</p>
<p>
さらに、不完全なエラーからの回復処理により以降のコマンドでも予期せぬエラーが発生する可能性がありました。
</p>
<li>ROLLBACK PREPARED 操作のレプリケーションに際して、レプリケーション元のタイムスタンプが確実に設定されるようになりました。  (Masahiko Sawada) (14)</li>
<li>トランザクションの最後のサブトランザクションのコミットタイムスタンプが記録されない可能性があり、修正されました。  (Alex Kingsborough, Kyotaro Horiguchi) (14)(13)(12)(11)(10)</li>
<li>チェックポイントに際して、pg_logical/mappingsサブディレクトリを必ず fsync するようになりました。  (Nathan Bossart) (14)(13)(12)(11)(10)</li>
<p>
一部のファイルシステムでは、この見落としによりシステムクラッシュ後に論理書き換えの状態ファイルが失われる可能性がありました。
</p>
<li>パーティションテーブルの拡張統計情報が作成されるようになりました。  (Justin Pryzby) (14)(13)(12)(11)(10)</li>
<p>
以前のバグ修正により、古い形式の継承ツリーに対する拡張統計の構築が無効になりましたが、パーティションテーブルに対する構築も無効になっており、不要な制限となっていました。今回の変更により、ANALYZE はパーティションテーブルの統計オブジェクトの値を計算できるようになりました。（しかし、autovacuum はパーティションテーブルを自動処理しないので、パーティションテーブルの統計情報を維持したい場合は、パーティションテーブルに対して定期的に手動 ANALYZE を実行する必要があることに注意してください。）
</p>
<li>継承ツリーの拡張統計情報を無視するようになりました。  (Justin Pryzby) (14)(13)(12)(11)(10)</li>
<p>
現在、拡張統計情報の値は継承ツリー全体ではなく各テーブルに対してローカルでのみ計算されます。しかし、この値が継承ツリーをまたがる問い合わせを計画する際に誤って参照されたため、デフォルトよりも悪い推定値になる可能性がありました。
</p>
<li>パーティションテーブルの行型が他の場所で複合型として使用されている場合、パーティションテーブルの列のデータ型を変更することが禁止されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
この制限は通常のテーブルでは長い間存在していましたが、見落としによりパーティションテーブルではチェックされていませんでした。
</p>
<li>レプリカアイデンティティ(REPLICA IDENTITY) のインデックスの一部である列に対する ALTER TABLE ... DROP NOT NULL が禁止されました。  (Haiying Tang, Hou Zhijie) (14)(13)(12)(11)(10)</li>
<p>
同じ禁止事項はすでに主キーインデックスに存在していました。
</p>
<li>ALTER TABLE .. ADD PRIMARY KEY USING INDEX の実行に際して、キャッシュされたテーブルの状態が正しく更新されるようになりました。  (Hou Zhijie) (14)(13)(12)(11)</li>
<p>
同時実行中のセッションが、テーブルに主キーがあるかどうかに関する判定を更新できなかったため、不正なロジカルレプリケーションの動作が発生する可能性がありました。
</p>
<p>
パブリケーションしているテーブルの UPDATE で、テーブルに ALTER TABLE で主キーを設定した後であっても、以下エラーが発生する動作が報告されました。
</p>
<pre>
ERROR:  cannot update table ... because it does not have a replica identity and publishes updates
</pre>
<li>REPLICA IDENTITY インデックスから切り替えを行う際、キャッシュされたテーブルの状態が正しく更新されるようになりました。  (Tang Haiying, Hou Zhijie) (14)(13)(12)(11)(10)</li>
<p>
同時実行中のセッションが、どのインデックスが REPLICA IDENTITY であるかの判定を更新できなかったため、不正なロジカルレプリケーションの動作が発生する可能性がありました。
</p>
<li>SP-GiSTインデックス作成で、インデックス対象列のデータ型が演算子クラスの宣言された入力型とバイナリ互換性がある場合でもエラーとなっていたのが修正されました。  (Tom Lane) (14)</li>
<p>
このような場合は動作すべきでしたが以下のエラーが発生していました。
</p>
<pre>
ERROR:  compress method must be defined when leaf type is different from input type
</pre>
<li>最も古い xmin値を計算する際、並列のバキュームとインデックス同時構築を無視できるようにようになりました。  (Masahiko Sawada) (14)(13)</li>
<p>
並列化されていない処理では既に無視されていましたが、並列化されたロジックでは機能していませんでした。その結果、xmin の限界値の前進が抑えられることで、バキュームのクリーンアップが遅れるなどの望ましくない影響がありました。
</p>
<li>式インデックスを更新するときのメモリリークが修正されました。  (Peter Geoghegan) (14)</li>
<p>
式インデックスを持つテーブルの多くの行を更新する UPDATE 文は、大量のメモリを消費する可能性がありました。
</p>
<li>多数のオブジェクトの所有権を変更する REASSIGN OWNED BY コマンド実行中にメモリリークが発生しないように修正されました。  (Justin Pryzby) (14)(13)(12)(11)(10)</li>
<li>不要なキャッシュアクセスを回避することにより、ロジカル変更を送信する walsender のパフォーマンスが向上しました。  (Hou Zhijie) (14)(13)</li>
<li>pg_hba_file_rules ビューでの cert認証方式のオプションの表示が修正されました。  (Magnus Hagander) (14)(13)(12)</li>
<p>
認証方式が cert の場合、clientcert=verify-full が暗黙的に指定されますが、pg_hba_file_rules ビューは誤って clientcert=verify-ca と報告していました。
</p>
<li>pg_log_backend_memory_contexts() で対象とされるセッションが、結果をサーバのログのみに送信するよう修正されました。  (Fujii Masao) (14)</li>
<p>
以前は、client_min_messages のレベルを高く設定すると、接続しているクライアントにもログメッセージが送信される可能性がありました。これはクライアントが要求していない動作です（そしておそらくワイヤープロトコル違反でした）。
</p>
<li>INSERT .. VALUES のルールにおける行全体の変数の表示方法が修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
行全体の変数は、var.* として出力されますが、ルールが再ロードされたときに個々の列に展開されるため、異なるセマンティクスとなっていました。これを防ぐために他の場所と同様に明示的なキャストが行われるようになりました。
</p>
<li>SQL標準の関数本体を逆コンパイルによって再構築したときに、INSERT ... SELECT 内の関数パラメータが適切に表示されるようになりました。  (Tom Lane) (14)</li>
<p>
これまでは、パラメータに名前が付いていても $n と出力されていました。
</p>
<li>空文字列に対して Unicode 文字列正規化を適用する場合の 1バイトのバッファオーバーランが修正されました。  (Michael Paquier) (14)(13)</li>
<p>
これによる実際の影響は、アライメントを考慮すれば限定的なものですが、デバッグビルドでは警告が発生していました。
</p>
<li>いくつかの誤ったアサートが修正または削除されました。  (Simon Riggs, Michael Paquier, Alexander Lakhin) (14)(13)(12)(11)(10)</li>
<p>
これらの誤りは、製品ビルドではなく、デバッグビルドのみ影響を受けました。
</p>
<li>libpq と ecpglib でマルチスレッド使用時における gettext() 初期化の競合状態が修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
エラーメッセージのローカライズに失敗する可能性がありました。
</p>
<li>libpq の PQcancel関数から strerror を呼び出さないようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
PQcancel はシグナルハンドラから安全に呼び出すことができるはずですが、strerror は安全ではありません。誤った使用法は、サーバへのキャンセルメッセージ送信に失敗した場合にのみ発生しますので、そのためおそらくこれまで報告がありませんでした。
</p>
<li>psql の \password コマンドで設定するパスワードは、接続元のユーザのものではなく、CURRENT_USER のものがデフォルトとなりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
これはドキュメントの動作と一致し、セッション開始後の SET ROLE または SET SESSION AUTHORIZATION を実行した場合に発生し得るパーミッションエラーを避けます。また、混乱を防ぐために操作対象のロール名がパスワードプロンプトに含まれるようになりました。
</p>
<li>親テーブルのトリガを識別するように psql の \d コマンドのクエリが修正されました。  (Justin Pryzby) (14)(13)</li>
<p>
パーティションにトリガがあり、親テーブルにも同じ名前の無関係な文レベルトリガが存在した場合、以前のコードでは「ERROR: more than one row returned by a subquery used as an expression」というエラーが発生していました。
</p>
<li>psql の \d コマンドで、テーブルの拡張統計オブジェクトが OID でなく名前でソートされるようになりました。  (Justin Pryzby) (14)</li>
<li>psql の列挙型のラベルをタブを使って補完する機能が修正されました。  (Tom Lane) (14)(13)</li>
<li>Windows の標準入力からの読み込みをデータソースまたは宛先に使用したときの障害が修正されました。  (Dmitry Koval, Juan Jose Santamaria Flecha, Michael Paquier) (14)</li>
<p>
これは、psql の \copy コマンド、または pg_recvlogical で「-f -」を付けた場合に影響がありました。「could not stat file」エラーが発生しました。
</p>
<li>psql や 他のクライアントプログラムでは、Ctrl+C シグナルハンドラからのgettext() 呼び出しを避けるようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
この誤りに起因する障害報告は確認されていませんが、gettext() は非同期シグナル安全な関数ではなく、安全とは言えません。
</p>
<li>pg_receivewal と pg_recvlogical の初期パスワード入力がキャンセルできるようになりました。  (Tom Lane, Nathan Bossart) (14)(13)(12)(11)(10)</li>
<p>
以前は、パスワード入力を求められている間、Ctrl+C でこれらのプログラムを終了することができませんでした。
</p>
<li>pg_dump がユーザ定義キャストをダンプするときの順序が、TYPE の直後、FUNCTION の手前に修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
まれに、出力スクリプトがユーザ定義キャストを作成する前に参照してしまう場合がありました。
</p>
<li>pg_dump の --inserts と --column-inserts モードが修正され、以前削除された列と生成列の両方を含むテーブルを扱えるようになりました。  (Tom Lane) (14)(13)(12)</li>
<li>pg_dump と pg_basebackup での誤ったエラー報告の可能性が修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
以前のコードでは、一部のカーネル呼び出しからのエラーをチェックできず、他のケースでは誤った errno 値を報告する可能性がありました。
</p>
<li>char(N) 列に対する contrib/btree_gist のインデックスによるインデックスオンリースキャン結果が修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
インデックスオンリースキャンでは末尾の空白が削除された列値が返されましたが、これはインデックス格納方法に起因したもので、想定の動作ではありませんでした。末尾空白の違いだけですが誤った問い合わせ結果です。
</p>
<p>
空白埋めをした char(N) 値を格納するようにコードが修正されました。インデックスの動作は REINDEX をしない限りすぐには反映されません。 REINDEX（インデックス再作成）をしない場合、空白が削除された値は、更新を行っていくなかで徐々に置き換えられていきます。インデックスオンリースキャン実行計画を使用しない問い合わせは、どの場合でも影響を受けません。
</p>
<li>postgres_fdw の非同期クエリの処理における稀なケースが修正されました。  (Etsuro Fujita) (14)</li>
<p>
これらのエラーは、外部テーブルのスキャンを並列化しようとすると、クラッシュまたは誤った問い合わせ結果を引き起こす可能性がありました。
</p>
<li>PL/Pythonの ビルド方法を決定するために、非推奨の distutils モジュールではなく、Python の sysconfig モジュールを使用するように configure が変更されました。  (Peter Eisentraut, Tom Lane, Andres Freund) (14)(13)(12)(11)(10)</li>
<p>
これにより Python 3.10 では distutils が非推奨になり Python 3.12 での削除が予定されている configure-time の警告が回避されます。 おそらく、Python 3.12 以降では configure --with-python は完全に失敗します。
</p>
<p>
sysconfig が Python 2.7 より前、また、Python 3.2 より前にも存在しなかったため、古くなった Python バージョンでの PL/Python のビルドはもはやできなくなります。
</p>
<li>OpenSSL なしでクロスコンパイルが再度可能となりました。  (Tom Lane) (14)</li>
<p>
configure ではターゲットシステムで /dev/urandom が使用可能であるはずと想定すべきでしたが、代わりに  configure が失敗していました。
</p>
<li>Windows 環境で Perl 5.28 以降を使用する PL/Perl コンパイルの失敗が修正されました。  (Victor Wagner) (14)(13)(12)(11)(10)</li>
<li>Python 3.11 以降での PL/Python コンパイルの失敗が修正されました。  (Peter Eisentraut) (14)(13)(12)(11)(10)</li>
<li>Visual Studio 2022 を使用したビルドがサポートされました。  (Hans Buschmann) (14)(13)(12)(11)(10)</li>
<li>MSVC ビルドシステムで .bat ラッパースクリプトを事前にディレクトリに移動することなく呼び出せるようになりました。  (Anton Voloshin, Andrew Dunstan) (14)(13)(12)(11)(10)</li>
</ol>

<div>
<a href="https://www.sraoss.co.jp/prod_serv/support/pgsql-mainte/?utm_source=sraoss-techblog&utm_medium=referral&utm_campaign=under-article-pgsql" rel="noopener" style="color:initial;" target="_blank" class="no-ext"></p>
<div style="background-color:#DAEFF6; padding:20px; border-radius:8px; text-align:center;">
SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。<br />
詳しくは<strong style="color:#2581c4;">弊社ホームページ</strong>をご覧ください。
</div>
<p></a>
</div>

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 11.14 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-14/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Mon, 29 Nov 2021 01:00:26 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.13]]></category>
		<category><![CDATA[PostgreSQL 11.14]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=7681</guid>

					<description><![CDATA[このリリースは 11.13 からの修正リリース（2021年11月11日リリース）です。 11.X からのアップデートではダンプ、リストアは不要です。 しかしながら、本リリースで修正されたいくつかの障害により既にインデック ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 11.13 からの修正リリース（2021年11月11日リリース）です。<br />
11.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、本リリースで修正されたいくつかの障害により既にインデックスに破損が生じている可能性があるため、該当するインデックスを再構築することが推奨されます。<br />
また、11.11 よりも前のバージョンから移行する場合には <a href="/tech-blog/pgsql/11-11">11.11 のリリース情報</a>も確認してください。</p>
<p><span id="more-7681"></span></p>
<h3>PostgreSQL 11.13 から 11.14 への変更点</h3>
<p>14.1、13.5、12.9、11.14、10.19、9.6.24 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>PostgreSQLサーバが SSL暗号化または GSS暗号化においてハンドシェイクが完了するまでは外来データを拒絶するようになりました。  (Tom Lane) (14)(13)(12)(11)(10)(9.6)</li>
<p>
これまで TCP接続にデータを挿入できる中間者は、暗号化で保護されているはずのデータベースセッションの冒頭に平文データを投入可能でした。サーバが認証データを要求してこない場合（例えば SSL証明書認証のみを使っている場合）に限られますが、これを悪用して偽の SQLコマンドをサーバに送ることができました。(CVE-2021-23214)
</p>
<li>libpq が SSL暗号化または GSS暗号化のハンドシェイクが完了する前は、外来データを拒絶するようになりました。  (Tom Lane) (14)(13)(12)(11)(10)(9.6)</li>
<p>
これまで TCP接続にデータを挿入できる中間者は、暗号化で保護されているはずのデータベースセッションの冒頭に平文データを投入可能でした。libpq の問い合わせ応答以外の細かい振る舞いのために実現は容易ではありませんが、これを悪用してクライアントの最初の問い合わせに偽の応答を挿入することがおそらく可能でした。別の攻撃は、セッションの初期に送られたクライアントのパスワードやその他の機微データを抜き出すことです。これは前項のサーバ側脆弱性と組み合わせて可能となります。(CVE-2021-23222)
</p>
<li>物理レプリケーションで、プライマリが部分的な WALレコードで終わっているWALセグメントを渡した後にクラッシュした場合について、修正されました。  (&Aacute;lvaro Herrera) (14)(13)(12)(11)(10)(9.6)</li>
<p>
ダウンするプライマリが不完全な WALレコードの残りを書き込み完了できなかった場合、以前のクラッシュリカバリロジックでは、それをバックアップして、不完全な WALレコードの最初から WAL を上書きしました。スタンバイサーバは既にその WALセグメントのコピーを持っているかもしれないので、これは問題がありました。不整合な次セグメントに遭遇して、手動の介入なしにはリカバリできないことになりました。
</p>
<p>
本障害により、更新処理を実行中のプライマリのクラッシュ後にスタンバイがレプリケーション継続できなくなる可能性があり、対処策はスタンバイで WALファイルを手動削除して再起動することでした。
</p>
<p>
クラッシュ後の再起動時に WALセグメント境界を越えたバックアップをしないように修正されました。その代わりに、次の WALセグメントの始めに新しいタイプ（OVERWRITE_CONTRECORD）の WALレコードを書いて、不完全な WALレコードは無視しなければならないことを知らせるようになりました。
</p>
<p>
この修正を適用する場合、新しい WALレコードタイプが生じるようになるため、プライマリより先にスタンバイサーバをアップデートするのが良いです。
</p>
<li>並列VACUUM がインデックスを取りこぼさないように修正されました。  (Peter Geoghegan, Masahiko Sawada) (14)</li>
<p>
テーブルが min_parallel_index_scan_size を上回る 2つ以上のインデックスを持つ場合に、並列VACUUM が min_parallel_index_scan_size を下回るインデックスを処理していませんでした。この結果、これらのインデックスは VACUUM で除去済みのヒープ上のエントリに対する参照を持つことになって、破損した状態となる可能性があります。
</p>
<p>
この問題は並列VACUUM を行わない autovacuum には影響しません。発生条件に該当する、サイズの大小が異なる複数のインデックスを持っていて手動VACUUM を行ったことがあるテーブルについて、REINDEX を行うことが推奨されます。
</p>
<li>CREATE INDEX CONCURRENTLY が直近の準備されたトランザクションを待つように修正されました。  (Andrey Borodin) (14)(13)(12)(11)(10)(9.6)</li>
<p>
準備されたトランザクションから直近に挿入された行が、新たなインデックスから無視されるかもしれませんでした。その結果、インデックスに依存する問い合わせが、その行を取りこぼすおそれがありました。
</p>
<p>
この問題に対する以前の修正は、CREATE INDEX CONCURRENTLY が検査したときに進行中の PREPARE TRANSACTIONコマンドを考慮できていませんでした。max_prepared_transactions &gt; 0 の準備されたトランザクション（二相コミット）が有効なサーバでは、CONCURRENTLY指定で作成されたインデックスを全て REINDEXすることが推奨されます。
</p>
<li>同時作成をしているインデックスで、新たな行に対するエントリ追加の失敗を引き起こす可能性のある競合状態が回避されました。  (Noah Misch, Andrey Borodin) (14)(13)(12)(11)(10)(9.6)</li>
<p>
これにより破損したインデックスが生じる可能性があります。実際には稀にしか発生しないとみられますが、この誤りは潜在的に CONCURRENTLY指定を付けたあらゆるインデックス構築または再構築に影響する可能性があります。同時作成したインデックスの全てを REINDEXすることが推奨されます。
</p>
<li>対象インデックスに付加された演算子クラスのパラメータを維持するようにREINDEX CONCURRENTLY が修正されました。  (Michael Paquier) (14)(13)</li>
<p>
REINDEX CONCURRENTLY 実行後にデフォルトパラメータになってしまう現象が発生していました。
</p>
<li>組込オブジェクト以外を含んだデータベースを複製するときの共有依存関係の誤作成が修正されました。  (Aleksander Alekseev) (14)</li>
<p>
データベースの複製は、テンプレートデータベースから新たなデータベースを作成するとき行われます。本誤動作の結果 pg_shdepend の内容が不正になります。原理的には本障害でオブジェクトを所有しているロールが削除可能になってしまう可能性がありますが、本障害の実際の影響は限定的と考えられます。
</p>
<li>パーティションテーブルにアタッチあるいはデタッチしているテーブルについて、リレーションキャッシュが確実に無効化されるようになりました。  (Amit Langote, &Aacute;lvaro Herrera) (14)(13)(12)(11)(10)</li>
<p>
本障害により、アタッチ/デタッチの後に既存のセッションからそのパーティションに対する直接の挿入/更新を行ったときに、アタッチ/デタッチ操作がリレーションキャッシュに反映されていないことによる、不適切な制約の適用等の誤動作を起こす可能性がありました。
</p>
<li>範囲型の作成時にパースツリーが破損する障害が、修正されました。  (Alex Kozhemyakin, Sergey Shinderuk) (14)</li>
<p>
CREATE TYPE がパースツリーの要素を誤って解放していて、続くイベントトリガや CREATE TYPE コマンドがプランキャッシュに格納されて後に再使用される場合に、（クラッシュや予期せぬエラー等の）問題が起きる可能性がありました。
</p>
<li>複合型のドメインの配列の要素の更新について修正されました。  (Tom Lane) (14)(13)(12)(11)</li>
<p>
「UPDATE tab SET fld[1].subfld = val」のようなコマンドが、配列要素が複合型ではなく複合型のドメインである場合に失敗して、クラッシュや誤った更新結果を引き起こしました。
</p>
<pre>
（障害発生例／クラッシュが生じる）
db=# CREATE TYPE typ11 AS (subfld1 int, subfld2 int);
db=# CREATE DOMAIN dom11 AS typ11 NOT NULL;
db=# CREATE TABLE tbl11 (id int, fld dom11[]);
db=# INSERT INTO tbl11 VALUES (1, '{"(1,2)","(3,4)"}'::dom11[]);
db=# UPDATE tbl11 SET fld[1].subfld1 = 1;
server closed the connection unexpectedly
</pre>
<li>FETCH FIRST WITH TIES と FOR UPDATE SKIP LOCKED の組み合わせが禁止されました。  (David Christensen) (14)(13)</li>
<p>
FETCH FIRST WITH TIES は同順位でない行を見つけるまで停止しないため、返すべき行数に加えてもう 1行を取り出す必要があります。また、現在の実装では FOR UPDATE が使われた場合は返さない行についてもロックを取得します。その結果、SKIP LOCKED オプションが指定された場合に望ましくない振る舞いが生じました。当面の対処として、この組み合わせが禁止されました。
</p>
<p>
以下の動作例では id=3 の行が応答に登場しない結果となります。
</p>
<pre>
（望ましくない動作の例）
db=# CREATE TABLE t12 (id int, n int);
db=# INSERT INTO t12 VALUES (1,10),(2,10),(3,30),(4,40);
db=# BEGIN;
     SELECT * FROM t12 ORDER BY n FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED;
 id | n
----+----
  1 | 10
  2 | 10
(2 rows)

（別セッションで以下を実行）
db=# SELECT * FROM t12 ORDER BY n FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED;
 id | n
----+----
  4 | 40
(1 row)
</pre>
<li>ALTER INDEX .. ALTER COLUMN .. SET (..) でのオプション指定が禁止されました。  (Nathan Bossart, Michael Paquier) (14)(13)</li>
<p>
これまでパーサが受け付けていて、ALTER TABLE の場合と同じパラメータが指定可能でしたが、これは文書記載がなく、実際には機能しない一方、オプションを付与するとその列やテーブルの削除ができなくなりました。
</p>
<li>numeric型の power() 関数で稀な場合の精度損失が修正されました。  (Dean Rasheed) (14)(13)(12)(11)(10)(9.6)</li>
<p>
第一引数が 1 に非常に近い場合に不正確な結果が生じる可能性がありました。「^」演算子の左辺が 1 に近い場合についても同様に該当します。
</p>
<li>Memoizeプランでハッシュ等価演算子の誤選択が回避されました。  (David Rowley) (14)</li>
<p>
本障害により、クラッシュまたは誤った問い合わせ結果が生じるおそれがありました。
</p>
<li>副問い合わせの式を関数にプルアップする際のプランナエラーが修正されました。  (Tom Lane) (14)(13)</li>
<p>
FROM にある関数が FROM句の副問い合わせの出力をラテラル参照する場合で、副問い合わせを外側の問い合わせに平坦化が可能である場合、関数の式へコピーされた式は完全には処理されませんでした。その結果、プランの実行時にクラッシュを引き起こすおそれがありました。
</p>
<pre>
（本障害でクラッシュを起こす問い合わせの例）
db=# SELECT * FROM (
       SELECT jsonb_path_query_array(mod-&gt;'lecs', '$[*]') AS lec
         FROM unnest(array['{"lecs": [{"id": "1"}]}'::jsonb]) AS um(mod)) AS ss,
           jsonb_to_recordset(ss.lec) AS j (id text);
</pre>
<li>列の範囲の見積に不完全な MCV のみのプランナ統計情報を信用して使わないように修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
ANALYZE で稀に MCV（most-common-values、最頻値）リストが作られてヒストグラムは作られないことがあります。このような場合、MCVリストのみでデータ全体をあらわせそうな場合に限って、MCVリストのみで列値の範囲を見積をするようになりました。
</p>
<li>サブトランザクション内でのポータルのスナップショット復旧について修正されました。  (Bertrand Drouvot) (14)(13)(12)(11)</li>
<p>
プロシージャがあるトランザクションをコミットやロールバックして、その次の明示的な動作が新たなサブトランザクション内である場合にスナップショット管理を誤っていました。その結果、不正なポインタが生じて、クラッシュを引き起こす可能性がありました。
</p>
<p>
典型的には PL/pgSQL で以下のような処理を行う場合に該当します。
</p>
<pre>
  FOR i IN 1..100 LOOP -- 何らかのループ
    BEGIN 
      {問い合わせを実行}
    EXCEPTION
      {条件に応じて COMMIT や ROLLBACK を実行してループを継続}
    END;
  END LOOP;
</pre>
<li>スナップショットのエクスポート後にトランザクションが失敗した場合に、正しくクリーンアップするようになりました。  (Dilip Kumar) (14)(13)(12)(11)(10)(9.6)</li>
<p>
この誤りは、同じセッションがスナップショットを再びエクスポートしようとした場合に限って問題を引き起こします。ありそうな該当シナリオは、レプリケーションスロットを作成して、それが何らかエラーで失敗して、その後に続けて他のレプリケーションスロットを作成しようとすることです。
</p>
<p>
予期せぬ「ERROR:  clearing exported snapshot in wrong transaction state」が発生する動作が報告されました。
</p>
<li>スタンバイサーバでオーバーフローしたサブトランザクション追跡の周回を防止しました。  (Kyotaro Horiguchi, Alexander Korotkov) (14)(13)(12)(11)(10)(9.6)</li>
<p>
この誤りにより、スタンバイサーバで顕著な性能低下をもたらすおそれがあります。該当した場合、SubtransSLRU についての過大な処理量がはっきり現れました。
</p>
<li>スタンバイサーバの昇格中に、（二相コミット機能の）準備されたトランザクションが適切に考慮されるようになりました。  (Michael Paquier, Andres Freund) (14)(13)(12)(11)(10)(9.6)</li>
<p>
同時実行中のセッションが取得したスナップショットで、準備されたトランザクションが省略される可能性がある限られた時間帯がありました。その後、そのセッションがスナップショットを使用してデータを更新すると、誤った結果やデータの破損が発生する可能性がありました。
</p>
<li>EXPLAIN が WorkTableScanノードにアタッチされたフィルタ条件を表示しようとした時の予期せぬエラーが修正されました。  (Tom Lane) (14)</li>
<p>
CTE (WITH句）を伴う問い合わせの EXPLAIN で、以下のエラーが出る動作が報告されました。
</p>
<pre>
ERROR:  could not find RecursiveUnion for WorkTableScan with wtParam 0
</pre>
<li>ALTER INDEX コマンドを使ってテーブルの名前を変更する際に、正しいロックレベルを使用するように修正されました。  (Nathan Bossart, &Aacute;lvaro Herrera) (14)(13)(12)</li>
<p>
歴史的な理由から、ALTER INDEX ... RENAME はあらゆる種類のリレーションに適用できます。インデックス名を変更するのに必要なロックレベルは、テーブル等その他のリレーション名を変更する場合より低いのですが、ALTER INDEX を使った場合には対象がインデックス以外であっても、誤って低いロックレベルが使用されていました。
</p>
<pre>
（誤動作例）
db=# CREATE TABLE t24a (id int);  CREATE TABLE t24b (id int);
db=# BEGIN;
db=*# ALTER TABLE t24a RENAME TO t24x;
db=*# ALTER INDEX t24b RENAME TO t24y;
db=*# ^Z

（別セッションでロックを確認）
db=# SELECT relation::regclass, locktype, mode FROM pg_locks WHERE relation IS NOT NULL;
 relation | locktype |           mode
----------+----------+--------------------------
 pg_locks | relation | AccessShareLock
 t24b     | relation | ShareUpdateExclusiveLock
 t24a     | relation | AccessExclusiveLock
(3 rows)
</pre>
<li>オブジェクトとそのオブジェクトを所有するロールが並行して同時に削除された場合に null-pointer-dereference によるクラッシュが発生することがあり、回避されました。  (&Aacute;lvaro Herrera) (14)(13)(12)(11)(10)(9.6)</li>
<li>lo_export() または関連する関数が失敗した場合のスナップショット参照のリーク警告が防止されました。  (Heikki Linnakangas) (14)(13)(12)(11)(10)(9.6)</li>
<p>
以前は下記のようなメッセージが出力されましたが、実際のリークはほとんど害のないものでした。
</p>
<pre>
WARNING:  Snapshot reference leak: Snapshot 0x5634afd61cb8 still referenced
</pre>
<li>CoerceToDomain式ノードの非効率なコード生成が修正されました。  (Ranier Vilela) (14)(13)</li>
<p>
本修正は DOMEIN型の列に値を投入したり、DOMAIN型に型キャストする場合のエグゼキュータ処理を効率化します。
</p>
<li>いくつかのリスト操作で O(N^2) の動作が回避されるようになりました。  (Nathan Bossart, Tom Lane) (14)(13)</li>
<p>
これにより、 (1)プライマリ上で多数の排他ロックを保持しているトランザクションをスタンバイでリプレイする場合、 (2)チェックポイント後に削除(unlink)されることになっているファイルが多数ある場合、 (3)ハッシュ集約に多くのバッチ(ディスク書き出し)が含まれる場合、 (4)pg_trgm が複雑な正規表現からインデックス可能な条件を抽出する場合、を含むいくつかのシナリオで処理速度低下が修正されました。
</p>
<p>
これらのうち、実際にユーザから報告されたのは (1) だけですが、それ以外も非効率なリスト削除により該当すると見られます。
</p>
<li>B-tree のポスティングリスト分割に関する防御的な検査が追加されました。  (Peter Geoghegan) (14)(13)</li>
<p>
この変更により、テーブルの TID の重複を含むインデックスの破損を検出できるようになります。
</p>
<li>BRIN の float8 または float4 の minmax_multi_ops インデックスにNaN を挿入する時のアサート失敗が回避されました。  (Tomas Vondra) (14)</li>
<p>
アサートを無効にした実運用むけビルドにおいては、このような場合、いくらか非効率的ですが間違ってはいないインデックスになります。
</p>
<li>自動VACUUM のランチャープロセスが pg_log_backend_memory_contexts() の要求に対してより迅速に応答できるようになりました。  (Koyu Tanigawa) (14)</li>
<p>
これまで数秒を要することがありました。
</p>
<li>認証処理で使われる HMACハッシュ計算におけるメモリリークが修正されました。  (Sergey Shinderuk) (14)</li>
<li>shared_memory_type が sysv の場合、huge_pages を on に設定することが禁止されました。  (Thomas Munro) (14)(13)(12)</li>
<p>
以前はこの設定は受け入れられていましたが、実装がないため何もしませんでした。
</p>
<li>PL/pgSQL の RETURN QUERY文における、クエリ型のチェックが修正されました。  (Tom Lane) (14)</li>
<p>
RETURN QUERY は、UPDATE RETURNING のようにタプルを返すことができる任意のクエリを受け入れるべきです。 v14 では誤って SELECT 以外のものを禁止していました。さらに、可変の RETURN QUERY EXECUTE では、クエリ型チェックがまったく適用されていませんでした。
</p>
<li>大域的でないデフォルト権限を正しくダンプするように、pg_dump が修正されました。  (Neil Chen, Masahiko Sawada) (14)(13)(12)(11)(10)(9.6)</li>
<p>
大域的な（限定なしの）ALTER DEFAULT PRIVILEGES コマンドが関数の EXECUTE などデフォルトである権限を取り消した後、限定付きの ALTER DEFAULT PRIVILEGES コマンドが選択されたロールやスキーマに対してその権限を再び付与した場合、pg_dump は制限付きの権限付与を正しくダンプできませんでした。
</p>
<li>ダンプされるパーティションテーブルに対して、pg_dump が共有ロックを取得するようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
pg_dump が子のパーティションのいずれかをロックすれば、パーティションテーブル自体に対する重要な DDL を防ぐのに十分であるためこの見落としはたいていの場合は無害なものでしたが、関連するロックが保持されないため、子のないパーティションテーブルをダンプするときに問題が発生する可能性がありました。
</p>
<li>PostgreSQL 8.3 より前のサーバからトリガ定義をダンプしようとした際のpg_dump のクラッシュが修正されました。  (Tom Lane) (14)(13)(12)(11)</li>
<li>pg_restore の無効なラージオブジェクトの TOCファイルに関するエラーメッセージ中の誤ったファイル名が修正されました。  (Daniel Gustafsson) (14)(13)(12)(11)(10)(9.6)</li>
<p>
以前は以下のようなファイル名が空のエラーメッセージが表示されていました。
</p>
<pre>
pg_restore: error: invalid line in large object TOC file "": ..
</pre>
<li>ソケットレベルの障害発生後、pgbench がゼロ以外のステータスで終了するようになりました。  (Yugo Nagata, Fabien Coelho) (14)(13)(12)</li>
<p>
望ましい動作は実行を完了した後、ステータス 2 で終了することで、そのように修正されました。また、ソケットレベル障害のエラー報告が修正されました。
</p>
<li>pg_amcheck が一時的なリレーションや、無効または準備ができていないインデックスをチェックしないようにしました。  (Mark Dilger) (14)</li>
<p>
これにより、ほぼ確実に矛盾しているように見える、役に立たないリレーションのチェックが回避されます。
</p>
<li>contrib/amcheck がスタンバイサーバで実行される際に、UNLOGGEDテーブルをスキップするようになりました。  (Mark Dilger) (14)</li>
<p>
このようなテーブルは空になりますし、UNLOGGEDインデックスもすでにスキップするようになっているため、このようにするのが適切です。
</p>
<li>pg_stat_statements が最大 1GB 単位でクエリテキストファイルを読み込むようになりました。  (Tom Lane) (14)(13)(12)(11)(10)(9.6)</li>
<p>
2GB 以上のファイルを一度に読み込もうとするとすると失敗する可能性があるため、複数回に分けて読み込むようになりました。
</p>
<li>postgres_fdw がデータ変換エラーを報告しようとする際に発生しうる NULLポインタのクラッシュが修正されました。  (Tom Lane) (14)(13)(12)(11)(10)(9.6)</li>
<li>内部実装の関数 GetSharedSecurityLabel() が、クリティカルなリレーションキャッシュエントリがまだ構築されていない新たに開始したセッションでも使用できるようになりました。  (Jeff Davis) (14)(13)(12)(11)(10)(9.6)</li>
<p>
（サードパーティモジュール以外で）影響があるのは contrib/sepgsql のみです。
</p>
<li>TAPテストを実行する際、モジュール自体のディレクトリを PATH に含めるようになりました。  (Andrew Dunstan) (14)</li>
<p>
これによりインストールされていないプログラムを検出できるようになりました。
</p>
<li>Windows のタイムゾーン名を IANAタイムゾーンに割り当てるのにCLDRプロジェクトのデータを利用するようになりました。  (Tom Lane) (14)(13)(12)(11)(10)(9.6)</li>
<p>
initdb は新たなクラスタのタイムゾーンパラメータに、システムのタイムゾーンに対応した IANAタイムゾーンを設定しようとします。これまで Windows で利用していたマッピングテーブルは何年も前に生成され、更新も散発的にしか行われないため、エラーが含まれていたり、最近追加されたゾーンが存在していなかったりと問題がありました。既存インストレーションには影響はなく、新しく初期化されたデータベースクラスタにのみ影響します。
</p>
<li>タイムゾーンデータファイルが tzdata release 2021e に更新されました。   (14)(13)(12)(11)(10)(9.6)</li>
<p>
フィジー、ヨルダン、パレスチナ、サモアで夏時間法が変更され、バルバドス、クック諸島、ガイアナ、ニウエ、ポルトガル、トンガの歴史的修正が行われています。
</p>
<p>
また、Pacific/Enderbury は Pacific/Kanton に名称変更されました。また、Africa/Accra、America/Atikokan、America/Blanc-Sablon、America/Creston、America/Curacao、America/Nassau、America/Port_of_Spain、Antarctica/DumontDUrville、Antarctica/Syowa の各ゾーンは、近くのより人口の多いゾーンに統合されました。これらの名前はエイリアスとして残されています。
</p>
<li>float4 と float8 のハッシュ関数が NaN に対して均一の結果を生成するように修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
PostgreSQL は浮動小数点型は全ての NaN が等しいと見なすため、ハッシュ関数が IEEE 754 規格に従って NaN である全てのパターンに対して同じハッシュコードを生成することが重要です。今までそれができていなかったため、ハッシュインデックスやハッシュを伴った実行計画で、正規化されていない NaN値（'-NaN'::float8 など）に対して、誤った問い合わせ結果がもたらされるおそれがありました。
</p>
<p>
このような NaN値が含まれる可能性がある場合には、浮動小数点型の列に対するハッシュインデックスを再作成することが推奨されます。
</p>
<li>wal_level が minimal に設定されている時 CREATE TABLESPACE のクラッシュリカバリでのデータ損失が防止されました。  (Noah Misch) (13)(12)(11)(10)(9.6)</li>
<p>
CREATE TABLESPACE から次のチェックポイントまでの間にサーバがクラッシュした場合、クラッシュリカバリが実施されても完全にデータが復元されない可能性がありました。wal_level が minimal 以外の場合には該当しません。
</p>
<li>パーティションテーブルがパブリケーションへ追加もしくは削除される際に、全てのパーティションのリレーションキャッシュが無効化されるようになりました。  (Hou Zhijie, Vignesh C) (13)</li>
<p>
無効化が行われていなかったことによって、既存セッションでロジカルレプリケーションが誤動作を起こす可能性がありました。
</p>
<li>FOR ALL TABLES と指定されたパブリケーションを作成もしくは削除する際に、リレーションキャッシュが無効化されるようになりました。  (Hou Zhijie, Vignesh C) (13)(12)(11)(10)</li>
<p>
無効化が行われていなかったことによって、既存セッションでロジカルレプリケーションが誤動作を起こす可能性がありました。
</p>
<li>修飾子が指定されていない同じ型へのキャストを破棄しないようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
例えば、numeric(18,3) と定義されている f1列の場合、パーサは f1::numeric の様なキャストを実行時には影響がないという理由で破棄していました。しかし、外側にあらわれる型は、numeric(18,3) ではなく numeric であるべきです。これは再帰的な UNION など、より大きな構造の型を正しく解決するために重要です。
</p>
<pre>
（ビュー定義で型キャストが無視される誤動作例）
db=# CREATE TABLE t51 (f1 numeric(18, 3));
db=# CREATE VIEW v51 AS SELECT f1::numeric AS n1 FROM t51;
db=# \d+ v51
                                View "public.v51"
 Column |     Type      | Collation | Nullable | Default | Storage | Description
--------+---------------+-----------+----------+---------+---------+-------------
 n1     | numeric(18,3) |           |          |         | main    |
View definition:
 SELECT t51.f1 AS n1
   FROM t51;
</pre>
<p>
旧動作が誤っていると考えられますが、非互換性を含む修正となります。
</p>
<li>現在のデータベースエンコーディングがサポートしていない ICU照合順序は作成できないようになりました。  (Tom Lane) (13)(12)(11)(10)</li>
<p>
これまでは作成はできていましたが、実際には照合順序は使用できず、削除することもできない状態となっていました。
</p>
<li>{0} 内の括弧をキャプチャする際の正規表現エラーを回避するようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
(.){0}...\1 の様な正規表現において、間違った後方参照番号が引き出され、下記のようなエラーやクラッシュ、アサート失敗が生じる可能性がありました。エラーを発生させずに後方参照がマッチしないと判断するように修正されました。
</p>
<pre>
ERROR:  invalid regular expression: invalid backreference number
ERROR:  invalid regular expression: quantifier operand invalid
</pre>
<li>正規表現の後方参照が、本来マッチすべきでない時にマッチしてしまうのを防ぐようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
正規表現エンジンは部分的なマッチを拒否した後のキャプチャした括弧のマッチデータ排除に関して不注意でした。これにより、定義された参照先がないために失敗するはずの場所で、後方参照が一致する可能性がありました。
</p>
<pre>
（誤動作例）
db=# select 'abcdef' ~ '^(.)\1|\1.';
 ?column?
----------
 t
(1 row)

（先頭で同文字が連続していないので部分マッチせず、全体としても f になるのが正しい）
</pre>
<li>反復ノード内の後方参照による正規表現の性能上のバグが修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
後方参照のロジックが正しくなく、必要以上に時間を要する箇所がありました。幸いなことに、この問題はほとんどの場合に他の最適化によって顕在化することがありませんでした。
</p>
<li>タイムゾーン付きの時刻を AT TIME ZONE に適用した際に、間違った結果を返す問題が修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
動的な TZ 略語でゾーンが指定されている場合に誤った問い合わせ結果が生じる可能性があります。
</p>
<pre>
（報告された誤動作例、CLT は -03 または夏時間で -04）
db=# SELECT '12:34 -02'::timetz AT TIME ZONE 'CLT';
     timezone
-------------------
 09:51:14-04:42:46
(1 row)
</pre>
<li>PlaceHolderVars の継承子テーブルへの転換の誤りが修正されました。  (Tom Lane) (13)(12)</li>
<p>
PlaceHolderVars は内部実装上のデータ構造です。この誤りにより、パーティションテーブルや継承テーブルを外部結合の外側（無ければ NULL になる側）に持つ問い合わせで、アサート失敗や実行計画の異常が生じる可能性がありました。実際の問題発生は稀であると考えられます。
</p>
<li>バックグラウンドワーカが LISTEN を実行できないようになりました。  (Tom Lane) (13)</li>
<p>
実行するための基盤が無いため、実行されてしまうと単に NOTIFY によるキューのクリーンアップを妨げる結果となります。
</p>
<li>他のバックエンドへの NOTIFY シグナル送信をトランザクションコミットの時に行うようになりました。  (Artur Zakirov, Tom Lane) (13)</li>
<p>
この変更によってプロシージャ内の COMMIT 直後に通知を送信できるようになりました。また、ロジカルレプリケーションワーカが通知を送信できるようになりました。これまではアイドル状態にならないと送信されず、これらのことができませんでした。
</p>
<li>WITH HOLD オプションによって前トランザクションから保留されている NO SCROLL指定のカーソルの巻き戻しを、拒否するようになりました。  (Tom Lane) (13)(12)(11)</li>
<p>
長い間 NO SCROLL カーソルを逆方向にフェッチすることは禁止されていましたが、歴史的背景により、クエリを完全に巻き戻してから再度フェッチすることは禁止されていませんでした。この例外は、特に巻き戻しに必要なデータを全て保持していない可能性のある保留されたカーソルの場合には不整合を引き起こしました（クラッシュが報告されています）。最悪のケースを防ぐためにスクロールできない保留されたカーソルの巻き戻しを禁止するようになりました。
</p>
<p>
非互換性を含む修正となります。
</p>
<li>WITH HOLD カーソルをトランザクション終了時点で保存するときに、既にカーソルが読み込み完了していた場合に、失敗しないように修正されました。  (Tom Lane) (13)(12)(11)</li>
<p>
クラッシュが生じる動作が報告されました。
</p>
<li>許可された最大長に増大したリレーションの検出が修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
これまでも 2^32 - 1 ブロックという最大長を超えてテーブルやインデックスを拡張する試みはストレージ処理の段階で拒絶されました。しかし、不整合な内部状態を防ぐにはより早い検知が必要で、バッファマネージャにおいてエラーを出すようになりました。
</p>
<p>
アサート失敗が報告されました。
</p>
<li>DO INSTEADルールを展開するときに、データ変更を伴う CTE（WITH句）の存在を確認するようになりました。  (Greg Nancarrow, Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
これが行われなったため、安全でないパラレルプラン選択などの問題が生じるおそれがありました。ルールが適用される問い合わせの実行時に「ERROR:  cannot assign XIDs during a parallel operation」が生じる動作が報告されました。
</p>
<p>
これからは、データ変更を伴う CTE を持つ問い合わせには DO INSTEDルールの適用はできず、そのことを示すエラーになります。
</p>
<pre>
（修正後の振る舞い例）
db=# CREATE TABLE t63a (i int);
db=# CREATE TABLE t63b (i int);
db=# CREATE RULE r63a AS ON INSERT TO t63a DO INSTEAD
       INSERT INTO t63b SELECT NEW.i;
db=# WITH cte1 AS (DELETE FROM t63a RETURNING *)
       INSERT INTO t63a SELECT * FROM cte1;
ERROR:  INSERT...SELECT rule actions are not supported for queries having data-modifying statements in WITH
</pre>
<li>拡張統計情報オブジェクトへの権限のない操作に対する誤ったパーミッションエラー報告が修正されました。  (Tomas Vondra) (13)(12)(11)(10)</li>
<p>
以前は意図したメッセージではなく以下のようなキャッシュルックアップエラーが出力されていました。
</p>
<pre>
ERROR:  cache lookup failed for type 27447
</pre>
<li>並列ワーカの誤ったスナップショット処理が修正されました。  (Greg Nancarrow) (13)(12)(11)(10)</li>
<p>
以前はトランザクション分離レベルが REPEATABLE READ よりも低かった場合、パラレルクエリで誤動作をすることがありました。
</p>
<p>
アサート失敗が報告されました。
</p>
<li>一時テーブルの TOASTテーブル変更を適切に無視するように、ロジカルデコーディングが修正されました  (Bertrand Drouvot) (13)(12)(11)</li>
<p>
ロジカルデコーディングは、ALTER TABLE によるヒープ書き換えなどで作られる一時テーブルの変更を通常は無視しますが、関連する TOASTテーブルについてそのようになっていませんでした。
</p>
<p>
これにより、パブリッシュされたテーブルを ALTER TABLE すると、その後で予期せぬエラーが生じることがありました。
</p>
<li>TOASTデータを正しく処理するために論理デコーディングのメモリ使用量計算が修正されました。  (Bertrand Drouvot) (13)</li>
<p>
アサート失敗やクラッシュを引き起こす可能性がありました。
</p>
<li>walreceiverプロセスが、終了する前に全ての必要なアーカイブ通知ファイルを 作成するのを保証するようになりました．  (Fujii Masao) (13)(12)(11)(10)(9.6)</li>
<p>
通知ファイルとは archive_status ディレクトリ下に作られる.ready や .done のサフィックスを持ったファイルです。
</p>
<p>
これまで walreceiver はちょうど WALセグメント境界で終了した場合、最後に受信したセグメントの通知ファイル作成に失敗していました。その結果、スタンバイでセグメントをアーカイブするのが遅れていました．
</p>
<li>バックアップマニフェスト生成における WAL範囲の計算が、タイムライン変更が伴う場合について修正されました。  (Kyotaro Horiguchi) (13)</li>
<p>
昇格直後のベースバックアップがpg_veryfybackup で失敗するケースが報告されていました。
</p>
<li>SELECT .. FOR UPDATE を使うルールで疑似リレーション OLD、NEW にロック処理を行わないように修正されました。  (Masahiko Sawada, Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
OLD や NEW を指定して SELECT .. FOR UPDATE を行うルールの実行で予期せぬエラーやクラッシュが生じていました。
</p>
<li>集約の FILTER句のパーサ処理が修正されました．  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
FILTER式が単純な boolean型の列の場合に、誤った意味解釈が行われて仕様外の動作（即ち、誤った問い合わせ結果）が生じる可能性がありました。また、FILTER式自体が boolean型を返す集約である場合にはエラーを出すべきですが、そのようになっておらず、実行時にクラッシュを起こすことがありました。
</p>
<pre>
（修正前バージョンでの障害発生例）
db=# CREATE TABLE t71 (i int, b boolean);
db=# INSERT INTO t71 VALUES (1, 't'),(2, 't'), (3, 'f');
db=# SELECT (SELECT max(0) FILTER (WHERE b IS TRUE)) FROM t71;
 max
-----
   0
(1 row)

db=# SELECT (SELECT max(0) FILTER (WHERE b)) FROM t71; -- 誤動作する
 max
-----
   0
   0

(3 rows)

db=# SELECT (SELECT array_agg(z.b) FILTER (WHERE bool_or(z.i &gt; 0))
       FROM t71) FROM t71 z; -- クラッシュする
server closed the connection unexpectedly
</pre>
<li>ALTER TYPE/DOMAIN/OPERATOR .. SET が拡張のメンバシップを変更しないように修正されました。  (Tom Lane) (13)</li>
<p>
拡張のスクリプトで実行された ALTER .. SET は、ターゲットとなるオブジェクトが拡張のメンバになっていなかった場合に、それを拡張のメンバにしてしまうことがありました。
</p>
<p>
拡張のスクリプトがその拡張に属さないオブジェクトにアクセスする理由はほとんど無いため、これ自体は大きな問題はありません。しかし、ALTER TYPE .. SET はその型に依存するドメインにも再帰的に効果を及ぼすため、それらも拡張のメンバになり、拡張のアップグレードスクリプトで望まない副作用を引き起こしました。
</p>
<li>LLVM 内でのエラー後に LLVM状態のクリーンアップを試みないように修正されました。  (Andres Freund, Justin Pryzby) (13)(12)(11)</li>
<p>
これにより、致命的な LLVM のエラーが起きた後にバックエンドが終了する際に起こりうるクラッシュを防止します．
</p>
<li>SP-GiSTインデックスのスキャンが統計ビューでカウントされることを保証するようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
SP-GiST のコードでは、タプルのカウンタは正しく進む一方で、インデックススキャン回数の加算が欠落していました。
</p>
<li>リカバリ中に recovery_min_apply_delay が変更された場合には、関連する待機間隔を再計算するようになりました。  (Soumyadeep Chakraborty, Ashwin Agrawal) (13)(12)(11)(10)(9.6)</li>
<p>
これにより設定変更が直ぐに効くようになります。
</p>
<li>simplehash.h のハッシュテーブルが 2^32 要素を超えた場合に無限ループになる誤りを修正しました．  (Yura Sokolov) (13)(12)(11)(10)</li>
<p>
これは数百GB の work_mem が設定されていない限り顕在化しないため、実際には発生していなかったものと見られます。
</p>
<li>ANALYZE実行における拡張統計の計算中のメモリ使用量が削除されました。  (Justin Pryzby, Tomas Vondra) (13)(12)(11)(10)</li>
<li>AIX において libpq の関数が欠落しており、修正されました。  (Tony Reix) (13)</li>
<p>
コード再編成の誤りで以下のドキュメント記載された関数がエクスポートされていませんでした。
</p>
<pre>
  pg_encoding_to_char()
  pg_utf_mblen()
  pg_char_to_encoding()
  pg_valid_server_encoding()
  pg_valid_server_encoding_id()
</pre>
<li>接続を試みている途中で malloc() に失敗してもエラー後に正しく回復できるように、ecpg が修正されました。  (Michael Paquier) (13)(12)(11)(10)(9.6)</li>
<p>
ecpg を使うクライアントで pthread の mutex が残ったままになっていて、リソースリークやデッドロックを起こす恐れがありました。
</p>
<li>PL/pgSQL の CALL文の引数で呼ばれる STABLE の関数を誤って評価していたものが修正されました。  (Tom Lane) (13)(12)(11)</li>
<p>
静的関数は古いスナップショットを使って呼ばれており、そのため、セッションのトップレベルコマンドの開始後に行われたデータベースの変更が見えていませんでした。
</p>
<li>PL/pgSQL で最も外側のブロックからの EXIT が可能になりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
明示的な RETURN を必要としないルーチンであれば、この使い方は有効でしたが、これまでは許されていませんでした。
</p>
<li>pg_ctl のハードコーディングされた生成されたコマンド長の上限が取り除かれました。  (Phil Krylov) (13)(12)(11)(10)(9.6)</li>
<p>
これにより、例えば postmaster に渡すコマンドラインオプションを多数指定する場合の制限がなくなります。なお、pg_ctl が扱うパス名についての制限は未だあり、殆どの場合 MAXPGPATH（デフォルト1024）バイトで制限されます。
</p>
<li>RLS（行単位セキュリティ）ポリシーむけにテーブルごとの問い合わせ作成を回避することで、また、反復的な format_type() の呼び出しを回避することで、pg_dump の性能が改善されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
これらの変更はローカルサーバからのダンプでは重要ではありませんが、リモートサーバからのダンプではネットワーク往復が少なくなることで顕著なメリットがあります。
</p>
<li>contrib/btree_gin の（char(n)ではなく）"char" 列に対するインデックスの誤りが修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
&lt; や &lt;= 演算子を使ったインデックススキャンが実行されたときに、誤った問い合わせ結果（返るべきエントリが返らない）が生じました。インデックス破損ではなく、検索ロジックの誤りに起因します。
</p>
<li>RISC-V アーキテクチャむけのスピンロックのサポートが追加されました。  (Marek Szuba) (13)(12)(11)(10)(9.6)</li>
<li>OpenSSL 3.0.0 がサポートされました。  (Peter Eisentraut, Daniel Gustafsson, Michael Paquier) (13)(12)(11)(10)</li>
<li>作成した OpenSSL の BIO（I/O 抽象化）オブジェクトに正しい型識別子を設定するようになりました。  (Itamar Gafni) (13)(12)(11)(10)(9.6)</li>
<p>
この誤りは、おそらく OpenSSL のインストールを監査する類のタスクを行うコードでのみ問題となります。しかし、形としては OpenSSL API に違反しているため修正されました。
</p>
<li>libpq の静的リンクのための pkg-configファイルが修正されました。  (Peter Eisentraut) (13)(12)</li>
<p>
PostgreSQL 12 以降から、長らく正しい pkg-configファイルが提供されていませんでした。
</p>
<li>pg_regexec() が範囲外の search_start パラメータに対してより頑健になりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
pg_regexec() は PostgreSQL の正規表現機能の内部実装関数です。
</p>
<p>
search_start が文字列の終わりを過ぎている場合に、これまではクラッシュの可能性がありましたが、REG_NOMATCH を返すようになります。この場合はおそらく PostgreSQLコアコードでは生じませんが、拡張モジュールから使われるかもしれません。
</p>
</ol>

<div>
<a href="https://www.sraoss.co.jp/prod_serv/support/pgsql-mainte/?utm_source=sraoss-techblog&utm_medium=referral&utm_campaign=under-article-pgsql" rel="noopener" style="color:initial;" target="_blank" class="no-ext"></p>
<div style="background-color:#DAEFF6; padding:20px; border-radius:8px; text-align:center;">
SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。<br />
詳しくは<strong style="color:#2581c4;">弊社ホームページ</strong>をご覧ください。
</div>
<p></a>
</div>

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 11.13 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-13/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Wed, 01 Sep 2021 02:06:30 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.12]]></category>
		<category><![CDATA[PostgreSQL 11.13]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=7239</guid>

					<description><![CDATA[このリリースは 11.12 からの修正リリース（2021年8月12日リリース）です。 11.X からのアップデートではダンプ、リストアは不要です。 しかしながら、11.11 よりも前のバージョンから移行する場合には 11 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 11.12 からの修正リリース（2021年8月12日リリース）です。<br />
11.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、11.11 よりも前のバージョンから移行する場合には <a href="/tech-blog/pgsql/11-11">11.11 のリリース情報</a>も確認してください。</p>
<p><span id="more-7239"></span></p>
<h3>PostgreSQL 11.12 から 11.13 への変更点</h3>
<p>13.4、12.8、11.13、10.18、9.6.23 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>射影ステップの繰り返し適用による誤った実行計画の作成が修正されました。  (Tom Lane) (13)(12)(11)</li>
<p>
2つの ProjectionPath（射影、ターゲットリストの処理を行うパス）が互いにスタックした場合、プランナが誤った実行計画を作成する可能性がありました。これを再現させる既知の手順は並列ソートのみですが、それ以外の発生パターンもあるかもしれません。本障害によりクラッシュまたは誤った問い合わせ結果が生じます。また、障害動作を狙って起こしてサーバのメモリ内容の漏洩を狙う攻撃も可能です。(CVE-2021-3677)
</p>
<p>
以下に再現例を示します。
</p>
<pre>
db=# CREATE TABLE t1 (c1 int, c2 int);
db=# INSERT INTO t1 VALUES (1, 2), (3, 4);
db=# SET parallel_setup_cost TO 0;
db=# SET parallel_tuple_cost TO 0;
db=# SET min_parallel_table_scan_size TO 0;
db=# SET max_parallel_workers_per_gather TO 4;

db=# SELECT generate_series(1, c1), array(SELECT generate_series(1, c1)) FROM t1 ORDER BY c2;
（修正前の誤った問い合わせ結果）
 generate_series |   array
-----------------+-----------
               1 | {1,2}
               2 | {1,2}
               1 | {1,2,3,4}
               2 | {1,2,3,4}
               3 | {1,2,3,4}
               4 | {1,2,3,4}
(6 rows)

（修正後の正しい応答）
 generate_series |  array
-----------------+---------
               1 | {1}
               1 | {1,2,3}
               2 | {1,2,3}
               3 | {1,2,3}
(4 rows)

（修正前の誤ったプラン、一部で c1列と c2列が取り違えられている）
db=# EXPLAIN (VERBOSE, COSTS off)
       SELECT generate_series(1, c1), array(SELECT generate_series(1, c1)) FROM t1 ORDER BY c2;
                      QUERY PLAN
-------------------------------------------------------
 ProjectSet
   Output: generate_series(1, t1.c2), (SubPlan 1), t1.c1
   -&gt;  Gather Merge
         Output: t1.c2, t1.c1
         Workers Planned: 3
         -&gt;  Sort
               Output: t1.c2, t1.c1
               Sort Key: t1.c2
               -&gt;  Parallel Seq Scan on public.t1
                     Output: t1.c2, t1.c1
   SubPlan 1
     -&gt;  ProjectSet
           Output: generate_series(1, t1.c2)
           -&gt;  Result
(14 rows)
</pre>
<li>SSL再ネゴシエーションがより完全に禁止されました。  (Michael Paquier) (13)(12)(11)(10)(9.6)</li>
<p>
SSL再ネゴシエーションはしばらく前から無効になっていましたが、クライアイントから再ネゴシエーションの要求があれば受けつけてしまい、悪意の狙って作られた要求によりクラッシュを起こすおそれがありました（OpenSSL の脆弱性 CVE-2021-3449 を参照）。OpenSSL 1.1.0h 以降のそれが可能なバージョンについて、再ネゴシエーションが完全に無効化されました。
</p>
<li>プロシージャ内の COMMIT または ROLLBACK の後にポータルレベルのスナップショットを復元するようになりました。  (Tom Lane) (13)(12)(11)</li>
<p>
この変更により、COMMIT または ROLLBACK の直後に TOAST化された値を取得しようとし、「no known snapshots」または「missing chunk number 0 for toast value」のエラーとなる場合が修正されます。
</p>
<p>
一部の拡張はポータル外で SQL を実行するかもしれません。このような拡張は事前に外部スナップショットの存在確認をする必要があります。以前はスナップショットを存在せずとも動作する場合もありましたが、今後は「cannot execute SQL without an outer snapshot or portal」のエラーとなります。
</p>
<pre>
（修正前の障害動作例）
db=# CREATE TABLE t3 (c text);
db=# INSERT INTO t3 VALUES ((SELECT string_agg(random()::text, ':') FROM generate_series(1, 1000)));
db=# INSERT INTO t3 VALUES ((SELECT string_agg(random()::text, ':') FROM generate_series(1, 1000)));
db=# DO $$
     DECLARE
       r record;
     BEGIN
       FOR r in SELECT c FROM t3 LOOP
         INSERT INTO t3 VALUES (r.c);
         COMMIT;
       END LOOP;
     END;
     $$;
ERROR:  no known snapshots
CONTEXT:  PL/pgSQL function inline_code_block line 5 at FOR over SELECT rows
</pre>
<li>不安定なクエリを読み取るカーソルの結果を保持する際の誤った動作が修正されました。  (Tom Lane) (13)(12)(11)</li>
<p>
以前は、クエリ結果全体を常に巻き戻して再読み取りしていましたが、行を再度取り出した際に以前とは異なる結果となる可能性があり、あとで大きな問題となっていました。NO SCROLL指定のカーソルは順序どおりにしか行を取り出せないため、読み取っていない部分のみを保持することで修正されました。SCROLL指定のカーソルは問題が残ったままですが、不安定なクエリで使用するのは安全でないことがすでにマニュアルに記述されています。そこで、その記述をより強調することで対処されました。
</p>
<p>
また、PL/pgSQL のクエリ結果による FORループで使用される暗黙カーソルに NO SCROLL指定を強制し、プロシージャ内のコミットでそのようなカーソルを保持する際の同様の問題が修正されました。
</p>
<pre>
（修正前の誤った問い合わせ結果の例）
db=# CREATE TABLE t4 (c1 int, c2 text);
db=# INSERT INTO t4 VALUES (1, 'foo'), (2, 'bar'), (3, 'baz');
db=# DO $$
     DECLARE
       c CURSOR FOR SELECT c1 FROM t4 ORDER BY c1 FOR UPDATE;
     BEGIN
       FOR r IN c LOOP
         UPDATE t4 SET c2 = c2 || ' ' || c2 WHERE c1 = r.c1;
         COMMIT;
       END LOOP;
     END;
     $$;

db=# SELECT * FROM t4;
 c1 |   c2
----+---------
  2 | bar
  1 | foo foo
  3 | baz baz
(3 rows)

(修正後の正しい結果)
 c1 |   c2
----+---------
  1 | foo foo
  2 | bar bar
  3 | baz baz
(3 rows)
</pre>
<li>SELECT ... GROUP BY GROUPING SETS (()) FOR UPDATE が拒否されるようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
グループ化セットなしの GROUP BY と同様に FOR UPDATE は拒否すべきですが、以前は、空のグループ化セットを正しく処理できず、エグゼキュータでクラッシュしていました。
</p>
<pre>
（修正前のクラッシュする問い合わせ例）
db=# SELECT NULL FROM t1 GROUP BY GROUPING SETS (()) FOR UPDATE;
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.

(修正後)
db=# SELECT NULL FROM t1 GROUP BY GROUPING SETS (()) FOR UPDATE;
ERROR:  FOR UPDATE is not allowed with GROUP BY clause
</pre>
<li>WITH 内のクエリが NOTIFY のみに書き換えられる場合を拒否するようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
以前はクラッシュしていました。
</p>
<pre>
（修正前のクラッシュ発生例）
db=# CREATE RULE r AS ON INSERT TO t DO INSTEAD NOTIFY n;
db=# WITH w AS (INSERT INTO t VALUES (0)) VALUES (0);
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.

（修正後は以下のエラーが出ます）
ERROR:  DO INSTEAD NOTIFY rules are not supported for data-modifying statements in WITH
</pre>
<li>結果が小数点以下 16383 桁を越える乗算をした場合にエラーとせずに結果を丸めるようになりました。  (Dean Rasheed) (13)(12)(11)(10)(9.6)</li>
<pre>
（修正前の動作）
db=# SELECT (0.1 - 2e-16383) * (0.1 - 3e-16383);
ERROR:  value overflows numeric format

（修正後の応答）
                                   ?column?
-------------------------------------------------------------------------------
 0.010000000000000000000000000000000(中略)000000000000000000000000000000000000
(1 row)
</pre>
<li>非常に大きな累乗をした際のごく稀なエラーと精度の低下が修正されました。  (Dean Rasheed) (13)(12)(11)(10)(9.6)</li>
<pre>
（修正前の誤動作例：エラーになる場合）
db=# SELECT 0.9999999999 ^ 70000000000000;
ERROR:  value overflows numeric format

（修正前の誤動作例：誤った問い合わせ結果が返る場合）
db=# SELECT 0.9999999999 ^ 23300000000000;
                                   ?column?
-------------------------------------------------------------------------------
 1.000000000000000000000000000000000...中略...000000000000000000000000000000000
(1 row)
</pre>
<li>to_char() に EEEE書式で 10 ^ (-10001) 未満の値を与えた場合のゼロ除算エラーが修正されました。  (Dean Rasheed) (13)(12)(11)(10)(9.6)</li>
<pre>
（障害動作例）
db=# SELECT to_char(1.2345e-16379::numeric, '9.999EEEE');
ERROR:  division by zero

（修正後の正しい応答）
     to_char
---------------
  1.235e-16379
(1 row)
</pre>
<li>pg_size_pretty(bigint) が numeric版と同様に正の値と同じ方法で負の値を丸めるように修正されました。  (Dean Rasheed, David Rowley) (13)(12)(11)(10)(9.6)</li>
<pre>
（正の値の応答）
db=# SELECT pg_size_pretty(10485247::bigint);
 pg_size_pretty
----------------
 10239 kB
(1 row)

（負の値に対する障害動作）
db=# SELECT pg_size_pretty(-10485247::bigint);
 pg_size_pretty
----------------
 -10 MB
(1 row)

（修正後の正しい応答）
 pg_size_pretty
----------------
 -10239 kB
(1 行)
</pre>
<li>pg_filenode_relation(0, 0) がエラーを出すのではなく NULL を返すようになりました。  (Justin Pryzby) (13)(12)(11)(10)(9.6)</li>
<p>
無効なテーブル空間の OID とファイルノード番号に対しては NULL を返すべきですが、以前は 0 を与えた場合に紛らわしいエラーとなっていました。
</p>
<pre>
（修正前のエラー応答）
db=# SELECT pg_filenode_relation(0, 0);
ERROR:  unexpected duplicate for tablespace 0, relfilenode 0
</pre>
<li>ALTER EXTENSION が拡張にオブジェクトを追加または削除する際に、ロックを取得するようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
以前は ALTER EXTENSION ADD/DROP と DROP EXTENSION が同時に実行できて、その結果、システムカタログを破損する可能性がありました。
</p>
<li>ALTER SUBSCRIPTION が空文字列のスロット名を拒絶するように修正されました。  (Japin Li) (13)(12)(11)(10)</li>
<pre>
（修正後のエラーが返る動作）
db=# ALTER SUBSCRIPTION s SET (slot_name = '');
ERROR:  replication slot name "" is too short
</pre>
<li>パーティションテーブルのトリガを新たなパーティションに複製するときに、トリガの有効/無効ステータスを確実にコピーするようになりました。  (&Aacute;lvaro Herrera) (13)(12)(11)</li>
<p>
これまではパーティションテーブルのトリガのステータスが、子テーブルに伝搬しませんでした。
</p>
<li>REFRESH MATERIALIZED VIEW CONCURRENTLY むけに生成された問い合わせで、別名の衝突を回避するようになりました。  (Tom Lane, Bharath Rupireddy) (13)(12)(11)(10)(9.6)</li>
<p>
mv と newdata など、特定の名前の列を含むマテリアライズドビューでコマンドが失敗していました。「ERROR: column reference "mv" is ambiguous」といったエラーが発生しました。
</p>
<li>PREPARE TRANSACTION がセッション寿命のロックとトランザクション寿命のロックの衝突を正しく検査するように修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
同じ勧告的ロックID値に対してセッション寿命とトランザクション寿命の両方のロックを持っている場合、トラザクションは準備された状態にできません。この制限は完全には検査されておらず、PREPARE TRANSACTION 実行時に PANIC を引き起こすおそれがありました。
</p>
<li>RLS（行単位セキュリティ）のポリシーに複数回リストされているロールをターゲットにした DROP OWNED BY の誤動作が修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
そのような場合、アサート失敗や「ERROR:  tuple already updated by self」が引き起こされました。
</p>
<li>DROP OWNED BY 実行中に RLS ポリシーからロールを削除する際の不要なエラーチェックが削除されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
特に、DROP OWNED BY を使うのにスーパーユーザであることを必須とする場合について、修正されています。
</p>
<li>CREATE COLLATION にて古い形式の Windowsロケール名を許容するようになりました。  (Thomas Munro) (13)</li>
<p>
ある時点から、古い形式のロケールに対して OS がバージョン情報を提供できないためにエラーにしていましたが、そのようなロケールを再度許容するようになりました。
</p>
<pre>
（13.3 バージョンでエラーになる例）
db=# CREATE COLLATION public.ja_jp (LOCALE = 'Japanese_Japan.932');
ERROR:  could not get collation version for locale "Japanese_Japan.932":
error code 87
</pre>
<li>行全体の変数を GENERATED句で利用できなくなりました。  (Tom Lane) (13)(12)</li>
<p>
GENERATED句で行全体の変数を利用することは、生成列がそれ自体もしくは他の生成列を参照できないというルールに違反しており、そのようなケースの動作が明白に定義されていませんでした。実際の動作としては、しばしばクラッシュを引き起こしました。
</p>
<pre>
（GENERATED句に行全体の変数を使用する例）
db=# CREATE TABLE t20 
       (a int PRIMARY KEY, b int GENERATED ALWAYS AS (num_nulls(t20)) STORED);
ERROR:  cannot use whole-row variable in column generation expression
</pre>
<li>GENERATED の式における tableoid の使用について修正されました。  (Tom Lane) (13)(12)</li>
<p>
システム列 tableoid に対して 0 や誤った値が取得される場合がありました。ALTER TABLE で後から生成列を加えた場合や、生成列を持つ外部テーブルにINSERT や UPDATE を行う時に誤動作が発生します。
</p>
<li>外部テーブルに対して高速デフォルトをセットしないようになりました。  (Andrew Dunstan) (13)(12)(11)</li>
<p>
外部テーブルのようにローカルにヒープストレージが存在しない場合、高速デフォルトは役に立たず、その後の操作で混乱が生まれます。バージョン11 で高速デフォルトが追加された際に対象のテーブルが通常テーブルであるかのチェックがなかったため追加されました。
</p>
<li>インデックス状態フラグをトランザクションとして更新できるようになりました。  (Michael Paquier, Andrey Lepikhov) (13)(12)(11)(10)(9.6)</li>
<p>
これにより、インデックス述部が IMMUTABLE と宣言されているけれども実際にはそうではない場合の処理で失敗するのを回避できます。CREATE INDEX CONCURRENTLY でアサート失敗が生じるケースが報告されました。
</p>
<li>CREATE/ALTER DOMAIN がキャッシュされた実行プランにあらわれたときに、プランのキャッシュエントリが破損しないようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
プリペアドステートメントとして、これら命令を実行したときに、「ERROR:  unrecognized node type: N」(Nは数値）という予期せぬエラーが生じるケースが報告されました。
</p>
<li>pg_stat_activity にて walsender の最新のレプリケーションコマンドが表示されるようになりました。  (Tom Lane) (13)(12)(11)(10)</li>
<p>
今までは最新の SQL コマンドが表示されており、実際には表示されている SQL コマンドではなくレプリケーションコマンドが実行されている場合に紛らわしいものとなっていました。
</p>
<li>postgresql.conf から設定項目が削除された場合でもpg_settings.pending_restart　が true にセットされるようになりました。  (&Aacute;lvaro Herrera) (13)(12)(11)(10)(9.6)</li>
<p>
pending_restart は再起動が必要な設定項目が変更された際は正しく表示されていましたが、設定項目自体が削除された場合に対応できていませんでした。
</p>
<li>64 ビットの Windows で work_mem × hash_mem_multiplier が 2GB を超えることが許容されました。  (Tom Lane) (13)</li>
<p>
これにより hash_mem_multiplier を数ギガバイトを超えるような大きなハッシュ集約のディスク書き出しを防ぐ目的で利用できるようになりました。
</p>
<li>外部テーブルを継承する通常テーブルに関する問い合わせにおける、誤った実行プラン作成が修正されました。  (Amit Langote) (13)(12)</li>
<p>
SELECT FOR UPDATE や関連するコマンドで、アサート失敗、もしくは、「ERROR:  could not find junk column」が発生していました。
</p>
<li>プラン作成において、FROM 要素が LATERAL であるときの、不変の FROM句内関数結果のプルアップが修正されました。  (Tom Lane) (13)</li>
<p>
問い合わせでクラッシュやアサート失敗を起こす動作が報告されました。
</p>
<li>新しいスタンバイが新しいプライマリに追随する際に稀に発生する障害が修正されました。  (Dilip Kumar, Robert Haas) (13)(12)(11)(10)(9.6)</li>
<p>
いくつかの条件が組み合わさった際にスタンバイが間違った WALタイムラインに従おうとする可能性がありました。
</p>
<li>トランザクションアボートのレコードの WALリプレイがファイル切り捨てを引き起こすときに、最小のリカバリポイントが更新されるようになりました。  (Fujii Masao) (13)(12)(11)(10)(9.6)</li>
<p>
ファイル切り捨ては元に戻せないため、そのレコードよりも前の時点でリカバリを止めることは安全ではありません。トランザクションがコミットされた場合で該当するケースは数年前に修正されていましたが、アボートのケースは修正されていませんでした。
</p>
<li>レプリケーションスロットが無効となった後に「必要とされる最も古いWALセグメント」の境界値を適切に進めるようになりました。  (Kyotaro Horiguchi) (13)</li>
<p>
全てのレプリケーションスロットが無効となった際に境界値を再計算しておらず、最終的にサーバの WAL ストレージが溢れる可能性がありました。
</p>
<li>walreceiver で、エラー発生後にキャッシュからのカタログ検索を試みなくなりました。  (Masahiko Sawada, Bharath Rupireddy) (13)(12)(11)(10)</li>
<p>
これはエラー後において安全な方法ではありません。
</p>
<li>スタンバイサーバにシャットダウンシグナルが送信された場合、まだ起動処理中でWAL受信を待っているであっても、直ちにシャットダウンを実行するようになりました。  (Fujii Masao, Soumyadeep Chakraborty) (13)(12)(11)(10)(9.6)</li>
<li>トランザクションコミットグループへの参加に失敗した際に、共有状態が正しくクリアされるようになりました。  (Amit Kapila) (13)(12)(11)</li>
<p>
タイミングによっては、後のセッションが同じ PGPROCオブジェクトを再利用する場合にアサート失敗が発生する可能性がありました。
</p>
<li>他のプロセスからの同時書き込みに際しても不正な relmapper のデータを読み込みを回避できるように、ロックが追加されました。  (Heikki Linnakangas) (13)(12)(11)(10)(9.6)</li>
<p>
relmapper は OID とファイルノードの対応を保持するデータで、ファイル名は pg_filenode.map です。
</p>
<li>並列B-treeインデックス構築の、ソート段階に関する進捗報告が改善されました。  (Matthias van de Meent) (13)(12)</li>
<p>
パラレルワーカによるソート処理の開始前にも状態報告するようになりました。
</p>
<li>レプリケーションプロトコル違反の検査が改善されました。  (Tom Lane) (13)(12)(11)(10)</li>
<p>
ロジカルレプリケーションワーカは多くの箇所でアサートを用いて、不適切なレプリケーションコマンドの検査を行っていましたが、通常のエラー処理に変更されました。
</p>
<p>
不正な入力に対して、デバッグビルドでアサート失敗で停止することも、実運用ビルドで検査が行われないことも、望ましくありません。
</p>
<li>パーティションテーブルのロジカルレプリケーションで更新時に発生しうるクラッシュが幾つか修正されました。  (Amit Langote, Tom Lane) (13)</li>
<li>ロジカルレプリケーションワーカでパーティションテーブルのAFTERトリガが発動する時に生じる可能性のあったクラッシュが修正されました。  (Tom Lane) (13)</li>
<li>複数ロジカルレプリケーションワーカが同じテーブルを TRUNCATEしようとする際に起こるデッドロックが修正されました。  (Peter Smith, Haiying Tang) (13)(12)(11)</li>
<p>
TRUNCATE実行時にサブスクライバ側で「ERROR: deadlock detected」が発生していました。
</p>
<li>投機的挿入（speculative insertions）のロジカルデコーディングにおける幾つかの誤りが修正されました。  (Dilip Kumar) (13)(12)(11)(10)(9.6)</li>
<p>
投機的挿入は INSERT .. ON CONFLICT .. で使われる処理です。メモリリークや予期せぬエラー、アサート失敗がもたらされる可能性がありました。
</p>
<li>ロジカルレプリケーションのデコーディングによるメモリリークが修正されました。  (Amit Langote) (13)</li>
<li>エラー発生後、データ型キャッシュのハッシュテーブルに無効なレコード型のエントリが残る問題が回避されました。  (Sait Talha Nisanci) (13)(12)(11)</li>
<p>
これは後のクラッシュやメモリリークを引き起こす原因となっていました。
</p>
<li>CREATE TABLE ... AS EXECUTE構文でエラー発生する一部の場合における、プランキャッシュの参照カウントの取りこぼしが修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
結果としてメモリリークが生じる可能性がありました。
</p>
<li>パラレルワーカ間のタプル記述子を共有するコードで競合状態が修正されました。  (Thomas Munro) (13)(12)(11)</li>
<p>
場合によってはクラッシュが発生する可能性がありました。
</p>
<li>checkpointerプロセスによる使われなくなったレプリケーションスロット無効化が、そのスロットを削除や更新しようとする処理と並行して行われたときの競合状態が修正されました。  (Andres Freund, &Aacute;lvaro Herrera) (13)</li>
<li>バックグランドワーカスロット（BackgroundWorkerSlots）を解放する際の潜在的な競合状態が回避されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
Intelハードウェアでは明白にバグが修正されたという結果が観察できないかもしれませんが、メモリオーダリング制御が弱いマシン上では問題が起きる可能性がありました。
</p>
<li>ソートのコードにおける潜在的なクラッシュが修正されました。  (Ronan Dunklau) (13)(12)(11)(10)(9.6)</li>
<p>
あるコードパスで NULLポインタを解放しようとする可能性がありました。本ケースは、コアサーバのソート利用では到達できないように見えますが、拡張から引き起こされる可能性がありました。
</p>
<li>破損データに対して B-tree ポスティングリストを分割するコードが堅牢化されました。  (Peter Geoghegan) (13)</li>
<p>
既存のエントリと同一の TID を持つアイテムを挿入しようとすると、クラッシュするのではなく、エラーを投げるようになりました。 これは決して起こるべきではありませんが、インデックスがそのテーブルと矛盾している時に場合に起こることが報告されています。
</p>
<li>SP-GiST のインデックス挿入における無限ループが防止されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
INCLUDE列がリーフインデックスタプルがページに収まらないほどのスペースを占めている場合、text_ops演算子クラスはタプルを収めるために無駄に無限ループに陥ってしまいました。11以前のバージョンには INCLUDE列がありませんが、演算子クラスのバグに対する良い防御策と思われるので、このループ防止の修正が後方適用されました。
</p>
<li>SP-GiST のインデックス挿入が、クエリキャンセル要求によって終了できることが保証されました。  (Tom Lane, &Aacute;lvaro Herrera) (13)(12)(11)(10)(9.6)</li>
<li>PL/pgSQL で INTO句に STRICT が指定されていないにもかかわらず、あたかも STRICT が指定されているかのように動作する可能性がある、初期化されていない変数のバグが修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<li>libpq の出力関数（PQprint）において、メモリ不足障害が発生しても処理を中断しないようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
これまでは abort(3) でプログラムを終了させていました。
</p>
<li>ecpg で numaric型の INT_MIN（通常は -2147483648）を integer に変換できるようになりました。  (John Naylor) (13)(12)(11)(10)(9.6)</li>
<p>
以前の ecpg の範囲チェックでは INT_MIN ではなく -INT_MAX を範囲内としていたため、-2147483648 が範囲外として拒否されていました。
</p>
<li>psql やその他のクライアントプログラムで不正にエンコードされたデータを扱う際に、文字列の末尾をオーバーランしないようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
文字列の終わり近くに不適切にエンコードされたマルチバイト文字があると、様々な処理ループが文字列の最後の NUL を越えて実行される可能性があり、その結果、後続のメモリに何があるかによって、検出不能な問題からプログラムのクラッシュまで様々な問題が発生します。これは CVE-2006-2313 を想起させますが、これらの特定ケースが注意を喚起させるセキュリティ上の重要性を持つとは思われません。
</p>
<li>有効/無効（あるいは REPLICA/ALWAYS）の状態が親テーブルのトリガと異なるパーティションテーブルのトリガを正しく処理するようにpg_dump が修正されました。  (Justin Pryzby, &Aacute;lvaro Herrera) (13)(12)(11)</li>
<p>
このような場合にダンプで指定されていた状態が失われていました。
</p>
<li>異なるタイムゾーンで作成されたダンプファイルで pg_restore を実行した場合に発生する「invalid creation date in header」という警告が回避されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
新しい glibc バージョンの mktime() の移植性の問題により、異なるタイムゾーンで作成されたダンプファイルに対して pg_restore を実行した時、下記のメッセージが出ていました。
</p>
<pre>
pg_restore: warning: invalid creation date in header
pg_restore: while PROCESSING TOC:
</pre>
<li>pg_upgrade が古いインストールの「oldestXID」の値を引き継ぐようになりました。  (Bertrand Drouvot) (13)(12)(11)(10)(9.6)</li>
<p>
以前、新しいインストールの「oldestXID」は（通常）すぐに周回防止の自動バキュームが強制実行されるような古い値に設定されていました。これはパフォーマンスの観点からは望ましくありません。さらに悪いことに、大きな値の autovacuum_freeze_max_age を使用しているインストールでは、アップグレード直後に不必要な強制シャットダウンが発生する可能性がありました。
</p>
<li>アップグレードすべき拡張を検出して警告を出すように pg_upgrade が拡張されました。  (Bruce Momjian) (13)(12)(11)(10)(9.6)</li>
<p>
これからは、拡張を新PostgreSQLバージョンでデフォルトとされるバージョンにアップグレードするのに必要な ALTER EXTENSION UPDATE コマンドを含む、スクリプトファイルが作成されます。
</p>
<li>pg_receivewal を圧縮WAL格納と非圧縮WAL格納の間で切り替える際の問題が回避されました。  (Michael Paquier) (13)(12)(11)(10)</li>
<li>contrib/postgres_fdw が生成列について有効に動作するよう修正されました。  (Etsuro Fujita) (13)(12)</li>
<p>
外部テーブルの生成列が外部テーブルの生成列をあらわす場合については、適切に動作するようになりました。
</p>
<p>
postgres_fdw は IMPORT でリモートテーブルの生成列を通常の列として取り込み、外部テーブルに INSERT を行う時に「ERROR: cannot insert a non-DEFAULT value into column "..."」というエラーが出ていました。import_generated オプション（デフォルトtrue）が追加され、true なら、IMPORT FOREIGN SCHEMA は生成列を取り込むようになりました。
</p>
<li>contrib/postgres_fdw で、エラーの後にカタログ検索を試みないようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
通常はこの方法で動作しますが、カタログアクセスが機能しないエラーが発生している可能性があるため、あまり安全ではありませんでした。この修正の副作用として、データ変換エラーに関するメッセージで、外部テーブルや外部列の実際の名前ではなく、クエリのテーブルやカラムのエイリアス（使用されている場合）が言及されるようになりました。
</p>
<li>トランザクション隔離のテストの基盤が改善されました。  (Tom Lane, Michael Paquier) (13)(12)(11)(10)(9.6)</li>
<li>キャッシュ上書きの検査のオーバヘッドが軽減されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<li>PL/Python のリグレッションテストが Python 3.10 でも通るように修正されました。  (Honza Horak) (13)(12)(11)(10)(9.6)</li>
<li>PostgreSQLコード内の実装における printf("%s", NULL) がクラッシュする代わりに (null) を出力するようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
これにより、ごく稀な場合でのサーバの堅牢性が向上し、printf の実装が一般的なライブラリと同様となります。
</p>
<li>ポイントインタイムリカバリが ROLLBACK PREPARED レコードで停止した際に出力する誤ったログメッセージが修正されました。  (Simon Riggs) (13)(12)(11)(10)(9.6)</li>
<p>
「recovery stopping before abort of transaction %u, time %s」と出力すべきメッセージが、これまでは、「recovery stopping before commit of transaction %u, time %s」と出力されていました。
</p>
<li>ALTER TABLEで誤ったリレーションタイプに対するエラーメッセージが改善されました。  (Kyotaro Horiguchi) (13)(12)(11)</li>
<pre>
（メッセージ改善例）
db=# CREATE VIEW v69 AS SELECT * FROM t1;
db=# ALTER TABLE v69 ALTER c SET STATISTICS 0;
ERROR:  "v69" is of the wrong type
（修正後のメッセージ）
ERROR:  "v69" is not a table, materialized view, index, partitioned index, or foreign table
</pre>
<li>エラーメッセージ内の「負でない (non-negative)」等がゼロを含むか明確な表現に置き換えられました。  (Bharath Rupireddy) (13)(12)(11)(10)(9.6)</li>
<pre>
db=# CREATE TABLE t70 (c int) PARTITION BY HASH (c);
db=# CREATE TABLE p70 PARTITION OF t70 FOR VALUES WITH (MODULUS 4, REMAINDER 0);

(修正前)
db=# SELECT satisfies_hash_partition('t70'::regclass, 0, 0, NULL);
ERROR:  modulus for hash partition must be a positive integer
db=# SELECT satisfies_hash_partition('t70'::regclass, 1, -1, NULL);
ERROR:  remainder for hash partition must be a non-negative integer

(修正後)
db=# SELECT satisfies_hash_partition('t70'::regclass, 0, 0, NULL);
ERROR:  modulus for hash partition must be an integer value greater than zero
db=# SELECT satisfies_hash_partition('t70'::regclass, 1, -1, NULL);
ERROR:  remainder for hash partition must be an integer value greater than or equal to zero
</pre>
<li>個別の libldap_rライブラリがなくなった OpenLDAP 2.5 で動作するように configure が修正されました。  (Adrian Ho, Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>libldap_rライブラリが存在しない場合は、libldapライブラリは暗黙的にスレッドセーフであると想定されます。
</p>
<li>make ターゲットに新たに world-bin および install-world-bin が追加されました。  (Andrew Dunstan) (13)(12)(11)(10)(9.6)</li>
<p>
これらは、ドキュメントをビルドまたはインストールしないことを除き、world および install-world と同じです。
</p>
<li>TAPテストの makeルール（prove_installcheck）がPGXS の使い方に沿って動作するように修正されました。  (Andrew Dunstan) (13)(12)(11)(10)(9.6)</li>
<li>JITのコードが今後の LLVM API の変更に備えて調整されました。  (Thomas Munro, Andres Freund) (13)(12)(11)</li>
<p>
LLVM 13 では、以前の JIT コンパイラではクラッシュをもたらす、互換性のない API の変更が行われています。
</p>
<li>GSSAPIライブラリから返る文字列が null終端していることを前提としないように修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
GSSAPI の仕様では文字列ポインタと長さを返すことになっています。実際には文字列は通常 null終端されているため、従来コードでもエラーは発生していませんが、AddressSanitizer から問題が報告されました。
</p>
<li>MSVC で GSSAPI を使ったビルドが可能になりました。  (Michael Paquier) (13)(12)(11)(10)(9.6)</li>
<p>
最新の Kerberosビルドとのさまざまな非互換性が修正されました。
</p>
<li>MSVC ビルドで --with-pgport が指定されている場合、pg_config が出力する configure オプションに含めるようになりました。  (Andrew Dunstan) (13)(12)(11)(10)(9.6)</li>
<li>PostgreSQL 10 を ICU 69 以降でビルドできるようになりました。  (Peter Eisentraut) (10)</li>
<li>contrib/pgcrypto で、シンボル名が OpenSSL と競合しないように修正されました。  (Tom Lane) (9.6)</li>
<p>
SHA224ハッシュを使った操作で valgrid がエラーを検知する可能性がありました。これは、アライメント用パディングバイトのメモリ破壊にすぎないため、実際には影響なさそうですが、念のため修正されました。
</p>
</ol>

<div>
<a href="https://www.sraoss.co.jp/prod_serv/support/pgsql-mainte/?utm_source=sraoss-techblog&utm_medium=referral&utm_campaign=under-article-pgsql" rel="noopener" style="color:initial;" target="_blank" class="no-ext"></p>
<div style="background-color:#DAEFF6; padding:20px; border-radius:8px; text-align:center;">
SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。<br />
詳しくは<strong style="color:#2581c4;">弊社ホームページ</strong>をご覧ください。
</div>
<p></a>
</div>

]]></content:encoded>
					
		
		
			</item>
	</channel>
</rss>
