<?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 13 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql-13/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>Tue, 13 Oct 2026 06:08:42 +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 13 &#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 13.23 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/13-23/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Mon, 15 Dec 2025 03:00:05 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 13]]></category>
		<category><![CDATA[PostgreSQL 13.22]]></category>
		<category><![CDATA[PostgreSQL 13.23]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=19092</guid>

					<description><![CDATA[このリリースは 13.22 からの修正リリース（2025年 11月 13日リリース）です。 13.X バージョン系列は本リリースが最終リリースとなります。 13.X からのアップデートではダンプ、リストアは不要です。 ま ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 13.22 からの修正リリース（2025年 11月 13日リリース）です。<br />
13.X バージョン系列は本リリースが最終リリースとなります。</p>
<p>13.X からのアップデートではダンプ、リストアは不要です。<br />
また、13.21 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/13-21/" rel="noopener">13.21のリリース情報</a>も参照してください。</p>
<p><span id="more-19092"></span></p>
<h3>PostgreSQL 13.22 から 13.23 への変更点</h3>
<p>18.1, 17.7, 16.11, 15.15, 14.20, 13.23 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>CREATE STATISTICSで、スキーマに対する「CREATE」権限の検査を行うようになりました。  (Jelte Fennema-Nio) (18)(17)(16)(15)(14)(13)</li>
<p>
これまでこの検査が省略されており、テーブル所有者は任意のスキーマに拡張統計情報を作ることができて、予期せぬ名前衝突をもたらすおそれがありました。(CVE-2025-12817)
</p>
<pre>
（バージョンアップ後は最後のuser1によるCREATE STATISTICSはエラーになる）
db1=# CREATE SCHEMA scm1;
db1=# CREATE TABLE public.tbl1 (id int, c1 text, c2 text);
db1=# ALTER TABLE public.tbl1 OWNER TO user1;
db1=# \c db1 user1
You are now connected to database "db1" as user "user1".
db1=> CREATE STATISTICS scm1.tbl1_c1_c2_stat ON c1, c2 FROM public.tbl1;
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=00eb646ea">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e2fb3dfa8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d20abb587">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2393d374a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=95cce5669">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8a2530ebc">&#167;</a></small></p>
<li>libpqで、メモリ割り当てサイズ計算での整数オーバーフローを回避するようになりました。  (Jacob Champion) (18)(17)(16)(15)(14)(13)</li>
<p>
libpqのいくつかの個所で検査が欠けていました。巨大な入力に対して整数オーバーフローが起きると小さすぎるバッファ確保となって、バッファ終端を超えた書き出しを引き起こしました。(CVE-2025-12818)
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7eb8fcad8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f5999f018">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=585fd9b3c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=91421565f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=96d2c7e96">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d6f0c0d6d">&#167;</a></small></p>
<li>JSON_VALUEなどのSQL/JSON関数がCOLLATE式を含むDEFAULT句を持つときの、内部エラー発生が防止されました。  (Jian He) (18)(17)</li>
<pre>
（エラー発生例）
db1=# SELECT JSON_VALUE('{"a":"1","b":"2"}', '$.c' RETURNING text 
                        DEFAULT '0' COLLATE "C" ON EMPTY);
ERROR:  unrecognized node type: 31
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dc9125111">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=09f86a42f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1baae827e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1e6dfdaa0">&#167;</a></small></p>
<li>グルーピングセットを伴った列指定の無いHAVING句での不正な最適化が回避されました。  (Richard Guo) (18)</li>
<p>
ここでのグルーピングセットはGROUPING SETS、ROLLUP、CUBEを含みます。また、列指定の無いHAVING句とは「HAVING false」のような指定です。本障害で誤った問い合わせ結果が発生します。
</p>
<pre>
（誤動作例：この場合の正しいSELECT結果は0行です）
db1=# CREATE TABLE t4 (id int, c1 int, c2 int);
db1=# INSERT INTO t4 VALUES (1,1,10), (2,2,20), (3,3,30), (4,4,40);
db1=# SELECT c1, c2, count(*) c FROM t4 GROUP BY CUBE(c1, c2) HAVING false;
 c1 | c2 | c
----+----+---
    |    | 0
(1 row)
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=40c242830">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ee49f2cf4">&#167;</a></small></p>
<li>Hash Right Semi Joinでパラレル処理を行なわないようになりました。  (Richard Guo) (18)</li>
<p>
この場合、結合で共有されるハッシュテーブルの更新で競合状態が生じるため、信頼できる動作が得られないと判断されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ef6168baf">&#167;</a></small></p>
<li>ソートされたAppend（ordered-append）プランの作成で起こりうるゼロ除算が回避されました。  (Richard Guo) (18)</li>
<p>
この誤りにより、劣ったプランが選択されたり、デバッグ用ビルドであればアサート失敗が発生しました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=500f64636">&#167;</a></small></p>
<li>ソート順のアクセスが可能であるけれどもインデックスオンリースキャンはできないインデックスタイプに対して、プランナでのエラー発生が修正されました。  (Maxime Schoemans) (18)</li>
<p>
本障害で予期せぬエラー「ERROR:  no data returned for index-only scan」が発生しました。これは組み込みのインデックスタイプでは発生しませんが、一部の拡張で問題となりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=74197bdc8">&#167;</a></small></p>
<li>Btreeインデックスのクリーンアップ処理で過度なアサートを除去しました。  (Peter Geoghegan) (18)(17)(16)(15)(14)(13)</li>
<p>
インデックススキャンでのアサート失敗が報告されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=61de81a49">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ae15cebc2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c160fd469">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ca0c93908">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=314004021">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=af302ff6b">&#167;</a></small></p>
<li>パラレルGINインデックスの作成で発生するおそれのあったメモリ不足エラー(「ERROR:  out of memory」)や「ERROR:  invalid memory alloc request size」エラーを回避するようになりました。  (Tomas Vondra) (18)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a26b753a0">&#167;</a></small></p>
<li>BRINの自動サマライズが必要なインデックス式のスナップショットを確実に提供するようになりました。  (Álvaro Herrera) (18)(17)(16)(15)(14)(13)</li>
<p>
これまでは、VACUUM時の自動サマライズが式インデックスで失敗して、プレースホルダのインデックスタプルが置き去りになって、BRINインデックスが時間とともに肥大化する原因となりました。
</p>
<p>
自動VACUUMで以下のエラーが発生するケースが報告されました。
</p>
<pre>
ERROR:  cannot execute SQL without an outer snapshot or portal
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=419ffde23">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f4b68b033">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6ef33c805">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=23ddadf68">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f0ad41716">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3c7b47974">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8733f0b54">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3b5007347">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=20442cf50">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bcfbd3f74">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=65b0d1f74">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ef81697fe">&#167;</a></small></p>
<li>テーブルサイズが2の32乗ページ近くなる場合、BRINインデックススキャンで整数オーバーフローが発生する可能性があり、修正されました。  (Sunil S) (18)(17)(16)(15)(14)(13)</li>
<p>
この問題により、無限ループに陥ったり、不要なページを余計にスキャンしてしまう可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=715983a81">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c4f5a59ab">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ef915bf93">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=810aaf7f2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=eea24eb0a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c28f8ca29">&#167;</a></small></p>
<li>JITが生成するタプルデフォーミングのコードで、格納データを誤ってゼロ拡張してしまう問題が修正されました。  (David Rowley) (18)(17)(16)(15)(14)(13)</li>
<p>
JITを使用しない場合はゼロ拡張ではなく符号拡張が行われるため、小さい整数データ型のDatumの表現がJIT使用時と一致しない場合がありました。多くの場合は問題になりませんが、プランノードがMemoizeの場合にエラー「ERROR:  could not find memoization table entry」が発生する事例が確認されています。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ceb51d09b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=10945148e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3398b0d02">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b8ecfbe5a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e4316ec4d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4afab175b">&#167;</a></small></p>
<li>ハッシュ化されたGROUPING SETSの処理中に、まれにクラッシュする問題が修正されました。  (David Rowley) (18)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0b6a02f03">&#167;</a></small></p>
<li>ハッシュ結合において、ハッシュテーブルのサイズ選択ロジックが誤っていた問題が修正されました。  (Tomas Vondra) (18)</li>
<p>
これにより、ハッシュ結合が必要以上のメモリを消費したり、メモリの割り当てが非効率になることがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=aa151022e">&#167;</a></small></p>
<li>統計情報を操作する関数について、テーブルを参照する際のロジックが改善されました。  (Nathan Bossart) (18)</li>
<p>
テーブルにロックを取得する前に権限チェックが行われるようになりました。対象は以下の関数です。
</p>
<pre>
pg_restore_relation_stats()
pg_clear_relation_stats()
pg_restore_attribute_stats()
pg_clear_attribute_stats()
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c8af5019b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=15d7dded0">&#167;</a></small></p>
<li>トリガーで使用される結果リレーション情報(ResultRelInfo)のキャッシュ処理に存在した誤ったロジックによるクラッシュが修正されました。  (David Rowley, Amit Langote) (18)(17)(16)(15)</li>
<p>
パーティションとその親テーブルで列構成が物理的に一致していない場合に、クラッシュする可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a2387c32f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0d3074615">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a546964db">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2992b9a07">&#167;</a></small></p>
<li>パーティションテーブルに対してEvalPlanQualが再チェックを行う際にクラッシュする問題が修正されました。  (David Rowley, Amit Langote) (18)</li>
<p>
EvalPlanQualによる再チェックは主としてREAD COMMITTED隔離レベルの問合せで使われる処理です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1296dcf18">&#167;</a></small></p>
<li>EvalPlanQual用の代替となるローカルでの結合プランを持たないforeign結合またはカスタム結合を、EvalPlanQualが適切に扱えない問題が修正されました。  (Masahiko Sawada, Etsuro Fujita) (18)(17)(16)(15)(14)(13)</li>
<p>
本来は、代替プランが用意されていない場合、FDWまたはカスタムのアクセスメソッドを通常どおり呼び出す必要がありますが、それが行われずクラッシュすることがありました。
</p>
<p>
EvalPlanQualによる再チェックは主としてREAD COMMIMTTED隔離レベルの問合せで使われる処理です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b14144325">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2bb84ea7e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5a9af4868">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4a08603a2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=24e74b962">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=12b0c0e51">&#167;</a></small></p>
<li>DETACH CONCURRENTLY実行時に、ハッシュパーティションの制約が重複して追加されてしまう問題が修正されました。  (Haiyang Li) (18)(17)(16)(15)(14)</li>
<p>
従来はALTER TABLE DETACH PARTITION CONCURRENTLYは、DETACHされた側のパーティションにパーティション制約のコピーを追加していました。この動作は、ハッシュパーティションの場合、DETACH後には関係がなくなったパーティションテーブルのOIDを保持したままとなるため問題がありました。具体的には、pg_dumpで取得したデータのリストアに失敗したり、パーティションテーブル削除後にDETACHしたテーブルへの操作が失敗するなどの問題が発生しました。
</p>
<p>
予期せぬ「ERROR:  could not open relation with OID 16384」や「ERROR: could not open relation with OID 16990」というエラーの発生が報告されています。
</p>
<p>
次期メジャーバージョンであるPostgreSQL 19以降では、これらの制約コピーは一切行われないようにする予定ですが、18以前では、影響を最小化するためハッシュパーティションの場合のみ制約のコピーをスキップするよう修正されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=08c037dff">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ea06f97ee">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b835759ec">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bdae98495">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b753be38a">&#167;</a></small></p>
<li>パーティションキーに生成列が利用できないようになりました。  (Jian He, Ashutosh Bapat) (18)(17)(16)(15)(14)(13)</li>
<p>
もともと生成列をパーティションキーに使うことは許可されていませんでしたが、行全体を参照させた場合など一部ケースでチェック漏れがあり、それらも禁止されるようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ba99c9491">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0b44f2443">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7180d56c5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=643a5e96c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=04345d7a4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7f239c72a">&#167;</a></small></p>
<li>COPY ... FROM ... WHERE句で生成列が使用できないようになりました。  (Peter Eisentraut, Jian He) (18)(17)(16)(15)(14)(13)</li>
<p>
これまでは、そのような列を参照しようとすると、不正な動作か分かりにくいエラー「ERROR:  unexpected virtual generated column reference」が発生していました。これは、生成列がまだ計算されていない段階でWHEREフィルタが実行されていたためです。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0f9e0068b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=07f787e57">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=26958f4d9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8278737bf">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ccfe28eb4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3717849e6">&#167;</a></small></p>
<li>無効とマークされているNOT NULL制約が付いた列を、識別列として設定できないようにされました。  (Jian He) (18)</li>
<p>
識別列はNOT NULLである必要がありますが、そのチェックがこの特殊なケースを見逃していました。修正後は以下のようにエラーメッセージが表示されるようになりました。
</p>
<pre>
(18.1での実行例)
db1=# CREATE TABLE notnull_tbl (a int, b int);
db1=# INSERT INTO notnull_tbl VALUES (NULL, 1), (200, 2);
db1=# ALTER TABLE notnull_tbl ADD CONSTRAINT nn NOT NULL a NOT VALID;
ALTER TABLE
db1=# ALTER TABLE notnull_tbl ALTER COLUMN a ADD GENERATED ALWAYS AS IDENTITY;
ERROR:  incompatible NOT VALID constraint "nn" on relation "notnull_tbl"
HINT:  You might need to validate it using ALTER TABLE ... VALIDATE CONSTRAINT.
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d9ffc2729">&#167;</a></small></p>
<li>並列VACUUMにおいて、解放済みメモリ使用（use-after-free）が発生する可能性が回避されました。  (Kevin Oommen Anish) (18)(17)</li>
<p>
このバグは通常のビルドでは影響が生じないようですが、理論的には危険となり得るものです。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=76613b539">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3549ffb6a">&#167;</a></small></p>
<li>pg_temp内の統計オブジェクトに対する可視性チェックが修正されました。  (Noah Misch) (18)(17)(16)(15)(14)(13)</li>
<p>
一時スキーマにある統計オブジェクトは、スキーマ修飾なしでは名前を指定できませんが、pg_statistics_obj_is_visible()はこの点を見落としており、状況に関わらずtrueを返す可能性がありました。その結果、psqlの\dXが誤ってpg_temp内の統計オブジェクトを一覧表示したり、pg_describe_object()などの関数が期待されるようにオブジェクト名をスキーマ修飾できないことがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d024160ff">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6778fbca6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ab16418ee">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d202ec1fb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5816baa9b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=afb2cce74">&#167;</a></small></p>
<li>データベース作成のWALリプレイ時に発生していた軽微なメモリリークが修正されました。  (Nathan Bossart) (18)(17)(16)(15)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=33e7b4a7c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f9993ac64">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c72b5c536">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=23b316c36">&#167;</a></small></p>
<li>pg_stat_replicationビューにおけるレプリケーション遅延の誤った報告が修正されました。  (Fujii Masao) (18)(17)(16)(15)(14)(13)</li>
<p>
いずれかのスタンバイサーバのリプレイLSNが進まなくなった場合、write_lagおよびflush_lag列が、最終的に更新されなくなることがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9670032cc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=62d5ee75b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2e55cf4ef">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=59b215f72">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a7ab6ce6a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7d7ebdb80">&#167;</a></small></p>
<li>無効なprimary_slot_name設定に関する重複したログメッセージが出力されないようにされました。  (Fujii Masao) (18)(17)(16)(15)(14)(13)</li>
<p>
以前は、primary_slot_nameに無効なスロット名が設定された状態で設定ファイルをリロードすると、postmasterだけでなく、すべてのバックエンドプロセスがWARNINGを出力してしまい、大量の重複ログが生成される可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6ff7ba9fe">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1db2870bb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4fd916eab">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=caf529aba">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f106f53df">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b00a16bae">&#167;</a></small></p>
<li>synchronized_standby_slotsが存在しないレプリケーションスロットを参照している場合の障害が回避されました。  (Shlok Kyal) (18)(17)</li>
<p>
以前は、サーバ起動時に存在しないスロットを指定してもチェックされず、後でパラレルクエリ実行時にエラーとなる可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b45a8d7d8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0024f5a10">&#167;</a></small></p>
<li>レプリケーションスロットの状態をディスクへ書き込む際に失敗した場合、未完成のスロット状態ファイルが削除されるようにされました。  (Michael Paquier) (18)(17)(16)(15)(14)(13)</li>
<p>
これまでは、ディスク容量不足などで書き込みに失敗すると、一時ファイルであるstate.tmpが残されてしまいました。これは、その後の状態書き込みをすべて妨げ、手動でのクリーンアップが必要になるという問題を引き起こしていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9a6ea00ac">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=42348839d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bfdd1a12d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0adf424b4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f57f2760e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c878d9808">&#167;</a></small></p>
<li>論理レプリケーションの並列適用ワーカにおけるロックタイムアウトシグナルの誤処理が修正されました。  (Hayato Kuroda) (18)(17)(16)</li>
<p>
これまでは、同じシグナル番号がワーカのシャットダウンとロックタイムアウトの両方に使用されており、混乱を招いていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=37fc5de43">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2f6e1a490">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a54c7a113">&#167;</a></small></p>
<li>ストリーミングWALからアーカイブWALへ切り替える際に、不要なWAL受信プロセスのシャットダウンを回避するよう修正されました。  (Xuneng Zhou) (18)(17)(16)(15)(14)(13)</li>
<p>
タイムライン変更中、スタンバイサーバのWALレシーバは新しいWALストリーミングの開始点を待機するために稼働し続ける必要があります。ところが、以前はシャットダウンと再起動を繰り返していたため、pg_stat_wal_receiverのstatus列が正しく出力されないなどのレプリケーション状態を正しく把握できない問題が発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a14201073">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e7340b484">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9b6109607">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=da5ea6c70">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a1b8b3b2e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=25b484080">&#167;</a></small></p>
<li>pgoutputの論理デコーディング中にエラーが起きた際に、既に解放されたキャッシュメモリにアクセスしてクラッシュする問題が修正されました。  (Vignesh C, Masahiko Sawada) (18)(17)(16)(15)</li>
<p>
論理デコーディング中にエラーが発生すると、同じセッション内での次回以降の論理デコーディング実行時にクラッシュが起こる可能性がありました。この問題は、pgoutputをpg_logical_slot_get_binary_changes()のようなSQL関数経由で呼び出した場合にのみ発生します。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=32b95fc71">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a61592253">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b07682bce">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c40761759">&#167;</a></small></p>
<li>ロジカルレプリケーションスロットの不必要に無効化されていたのが修正されました。  (Bertrand Drouvot) (18)(17)(16)</li>
<p>
以前は、スロットが競合状態から非競合状態に移行しても無効化が行われる場合があり、不要な無効化が発生していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bf3dba508">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f3fb6bc9f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e3714dc05">&#167;</a></small></p>
<li>ロケール設定において、C照合順序の特殊ケースが再度有効化されました。  (Jeff Davis) (18)</li>
<p>
この修正により、データベース選択前のバックエンド起動初期に共有カタログへアクセスする際にエラーが発生してしまう問題が修正されました。PostgreSQLのコアコードで問題は確認されていませんが、一部の拡張では問題となっていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3ebea75f9">&#167;</a></small></p>
<li>Windows管理者権限の確認処理で失敗した際のメッセージ出力が正しく行われるように修正されました。  (Bryan Green) (18)(17)(16)(15)(14)(13)</li>
<p>
以前は、この処理でクラッシュするか、少なくとも役に立たないメッセージが表示される可能性がありました。ただし、実際にこのようなケースが報告されたことはないため、この問題が発生するのは極めて稀です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b48ae226e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4c53519e1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9883e3cd1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f91666c83">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e91eb4ad6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=75a555d61">&#167;</a></small></p>
<li>libsanitizer使用時に発生する可能性のあるクラッシュを回避するよう修正されました。  (Emmanuel Sibi, Jacob Champion) (18)(17)(16)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6d8acb777">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a9515f294">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c775bf048">&#167;</a></small></p>
<li>64bit Windowsのデバッグビルドで発生していた、誤ったメモリコンテキストチェック警告が修正されました。  (David Rowley) (18)(17)(16)(15)(14)(13)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=af3a79e08">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bd6f986c9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cdc04a6c3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f3420e006">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=86bd9497f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7b955c227">&#167;</a></small></p>
<li>PL/pgSQLの代入文でGROUP BY DISTINCTが正しく処理されるように修正されました。  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
DISTINCTオプションがパーサで記録されず、コマンドが通常のGROUP BYと同じように扱われていました。今回の修正により、DISTINCTが正しく認識されるようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=78a284b0b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3fc9aa5b0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b7f6798c0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9ca79896a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0be39b4b1">&#167;</a></small></p>
<li>PL/Python内でSQLエラーを処理する際のメモリリークが修正されました。  (Tom Lane) (18)(17)(16)(15)(14)(13)</li>
<p>
以前のマイナーリリースで導入された修正によって、セッション存続期間メモリが解放されない問題がありました。今回の修正でメモリリークが回避されるようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=447a794f6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fbc41a145">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cbfd4d0f8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4cde73259">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7fb8c9240">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d90c92d1c">&#167;</a></small></p>
<li>libpqのGSSAPI処理におけるWindows上のソケット関連エラーの扱いが修正されました。  (Ning Wu, Tom Lane) (18)(17)(16)(15)(14)(13)</li>
<p>
以前は、GSSAPIを使ったデータの暗号化／復号処理で、接続ソケットのエラーを正しく認識できず、Windows上で接続に失敗する場合がありました。今回の修正により、Windows特有のエラー報告に対応し、接続が正しく行われるようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d83879a32">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1c4671f7b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=46c4478db">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=771b106d1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f46d77377">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fc287cf3c">&#167;</a></small></p>
<li>継承子テーブルの列に対する非継承の（子テーブル固有の）NOT NULL制約が、正しくダンプされるよう修正されました。  (Dilip Kumar) (18)(17)</li>
<p>18より前のバージョンのサーバからのダンプで、そのような制約定義の出力が欠損していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0fe07fa11">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c945b06d5">&#167;</a></small></p>
<li>pg_dumpにおいて外部キー制約の並び順について修正されました。  (Álvaro Herrera) (18)</li>
<p>
これにより、他のオブジェクト種別と同様に、外部キー制約も一貫した順序で出力されるようになりました。これまでは制約名ではなくOID番号の順になっていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=162e70ea0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7419c99a2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=06c1ee6b7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4cc3b4445">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6062c3db3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d20df9590">&#167;</a></small></p>
<li>pg_dumpおよびpg_restoreにおけるデータ圧縮ロジックについて、各種のエラーが修正されました。  (Daniel Gustafsson, Tom Lane) (18)(17)(16)(15)(14)(13)</li>
<p>
いくつかの箇所でエラーチェックが欠落または不正確であり、さらに、ビッグエンディアンのハードウェア環境下では移植性の問題が発生することもありました。
</p>
<p>
この問題は、ディレクトリ形式ダンプ内のTOCファイルを手動で圧縮した場合にのみ発生します。そのため、通常の利用ではほとんど遭遇しないはずです。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=92268b35d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ec017a305">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6a4009747">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bf18e9bd7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1518b7d76">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=aa1fcd087">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2efca1633">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c865f5b9f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8b9924bce">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=40dc710a6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=33276cd02">&#167;</a></small></p>
<li>pgbenchで「COPY」操作が開始された場合に正しくエラーを返すようになりました。  (Anthonin Bonnefoy) (18)(17)(16)(15)(14)(13)</li>
<p>
pgbenchは仕様としてCOPYに対応していませんが、これまでエラー処理が完備されておらず、無限ループに陥っていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c00637b5f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=de6de069d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=640590bb4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b5cefc197">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9b3beb7c6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f1a2f3a0c">&#167;</a></small></p>
<li>pgbenchにおける複数エラーの報告が修正されました。  (Yugo Nagata) (18)(17)(16)(15)(14)(13)</li>
<p>
これまでは2回連続でPQgetResult呼び出しが失敗した場合、pgbenchが誤ったエラーメッセージを報告する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=29aabbc43">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a912118c6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=36c4d30c8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bdccb6302">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cb21e1f92">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7d7e81d1e">&#167;</a></small></p>
<li>pgbenchのパイプラインモードにおいて、エラー処理に関する不正確なアサートが修正されました。  (Yugo Nagata) (18)(17)(16)(15)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c736808e0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f39d9164b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8b2e290bd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=704f51771">&#167;</a></small></p>
<li>pg_combinebackupでファイルごとのメモリリークが修正されました。  (Tom Lane) (18)(17)</li>
<p>
テーブル等のオブジェクト数が多いときに影響があります。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e2072b47b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4eb6992af">&#167;</a></small></p>
<li>contrib/pg_buffercacheの関数が確実にキャンセルできるようになりました。  (Satyanarayana Narlapuram, Yuhang Qiu) (18)(17)(16)(15)(14)(13)</li>
<p>
これまで一部のコードパスで、割り込みを確認せずに長時間処理が続く可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=71aa2e114">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b6090ed96">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=815fcfb20">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=eb9ee4d18">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=79643105a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7d8d36289">&#167;</a></small></p>
<li>contrib/pg_prewarmで、インデックスの権限チェックが修正されました。  (Ayush Vatsa, Nathan Bossart) (18)(17)(16)(15)(14)(13)</li>
<p>
pg_prewarm()関数は、プリウォーム対象のリレーションに対して「SELECT」権限を必要とします。しかし、インデックス自体にはSQL権限が存在しないため、非スーパーユーザーはインデックスをプリウォームできませんでした。これを解決するために、今後はインデックスが属するテーブルに対する「SELECT」権限を確認するようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3ccf8e9ac">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a0551bc57">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fae0ce5e3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6c03ae8d6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f146eb45c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=19a64f567">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c29d32d27">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d4e8c37cc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c26a8eaf6">&#167;</a></small></p>
<li>contrib/pg_stat_statementsで、SQL文のテキスト内で複数の定数が同じ位置に割り当てられた場合にクラッシュする不具合が修正されました。  (Sami Imseih, Dmitry Dolgov) (18)</li>
<p>
特に「WHERE x IN ($1 /*, ... */)」のようにカンマ区切りの値の列挙を短縮している場合に問題が発生しました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b1635c166">&#167;</a></small></p>
<li>contrib/pgstattupleで、すべてゼロのページ、無効なインデックスページについて、より頑健な動作になりました。  (Nitin Motiani) (18)(17)(16)(15)(14)(13)</li>
<p>
すべてゼロのページは空き領域として数え、無効なインデックスページ（ページの特殊領域サイズチェックに基づいて判断される）は無視するようになりました。
</p>
<p>
これまでは、すべてゼロのページは、Btreeインデックスでは空き領域として数え、hashとGiSTインデックスではエラーが発生し、一貫性がありませんでした。また、無効なインデックスページではエラーが発生していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fc295beb7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=036decbba">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c0f9fe877">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=49b5f0b53">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ee2dbcad0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c207bf473">&#167;</a></small></p>
<li>Clangコンパイラの仕様に合わせて、読み取りと書き込みのバリアマクロが強化されました。  (Thomas Munro) (18)(17)(16)(15)(14)(13)</li>
<p>
Cコンパイラによるメモリアクセスの並べ替えを防ぐために、メモリバリアとして__atomic_thread_fence()関数が利用できると想定されていましたが、Clangでは十分なバリアになりませんでした。
</p>
<p>
少なくともRISC-V、MIPS、LoongArchのマシンで誤ったコードが生成される可能性がありました。本修正でClangでも問題なく利用できる明示的なコンパイラバリアが追加されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f8ccab0e9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=03d9140cb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2f76ffe5e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1c7cba4c5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d8ba910b0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=77b5b2c6f">&#167;</a></small></p>
<li>PGXS拡張構築基盤が各国語対応のpoファイルのビルドに対応するように修正されました。  (Ryo Matsumura) (18)(17)(16)(15)(14)(13)</li>
<p>
これまで「make USE_PGXS=1 update-po」が正しく動作しませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6aa04a60c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a8933194e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a506b0c0a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=33202cba8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=56cd332f8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f768f5a7d">&#167;</a></small></p>
<li>JSON作成関数（JSON_OBJECT()など）を非STRICTとして正しく処理するようになりました。  (Tender Wang, Richard Guo) (17)(16)</li>
<p>
これらの関数は、1つ以上のnull入力があっても、null以外の結果を返す場合があるので非STRICTです。これまでプランナはこれらの関数をSTRICTであると誤って分類してクエリ変換を行う可能性がありました。そのため、誤った問い合わせ結果が生じる可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d719e2ecb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=62397bb18">&#167;</a></small></p>
<li>「SIMILAR TO」正規表現内の文字クラスの処理の不具合が修正されました。  (Laurenz Albe) (17)(16)(15)(14)(13)</li>
<p>
「SIMILAR TO」パターンマッチング式からPOSIX形式の正規表現への変換について、直近前バージョンでの修正において特殊なケースについて不具合がありました。
</p>
<p>
不具合により、開き括弧の直後にエスケープ文字があり、エスケープシーケンスの直後に閉じ括弧がある場合（例：[\w]）、閉じ括弧が文字クラスの終了として認識されなくなっていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e09adb5b9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=281ad4ed1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9fd531534">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f75ff1b14">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=308773617">&#167;</a></small></p>
<li>集約関数の引数に含まれるサブクエリが、スコープ外のCTEをFROMで参照している場合の解析が修正されました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
このようなCTE参照は、外側のクエリの列参照のように動作する必要がありますが、それが考慮されておらず、プランナやエグゼキュータで不明瞭なエラーを引き起こしていました。
</p>
<p>
「ERROR:  could not find CTE ...」が発生するケース、クラッシュするケース、アサート失敗するケースが報告されました。また、誤った問い合わせ結果が生じる場合もありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e830896c1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7df74e635">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=afd18f276">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=31bf09632">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b649ef244">&#167;</a></small></p>
<li>プランナがSubPlanのコストを見積もる際に、稀にエラー「ERROR:  no relation entry for relid」が発生する不具合が修正されました。  (Richard Guo) (17)(16)(15)(14)(13)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f34202f51">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=79ade5873">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=53e35fb56">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=160ef51c8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8c02d92c6">&#167;</a></small></p>
<li>プランナがパーティションテーブルを展開する際に解放済みメモリ使用(use-after-free)の脆弱性が生じる可能性があり、修正されました。  (Bernd Reiß) (17)(16)(15)</li>
<p>
発生するケースは、パーティションを展開する際に最後の有効なパーティションが並行する別プロセスから同時に削除(DROP)された場合に限られます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ed394c4bd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f0fe1da50">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8286bce0a">&#167;</a></small></p>
<li>複数のスキャン条件を持つGINインデックススキャンで無限ループに陥る可能性があり、修正されました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
GINインデックスは一致しないエントリを除くスキャン条件（例えば、tsqueryの「!term」句など）を処理できます。これまで、そのような条件がスキャン条件の配列の先頭にあると、そのような条件と通常の条件が混在するクエリが無限ループになることがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=456c6a05d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d532069c3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=34249b3b5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4a593043e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3e0f5f00b">&#167;</a></small></p>
<li>GINインデックススキャンを割り込みでキャンセルできるようになりました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
一部のコードパスで長時間割り込みを検査せずに実行される可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d17abaea8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=25eadfd0f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a9c1b9c1c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a7da746c1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b2d71c455">&#167;</a></small></p>
<li>プランノードTID ScanおよびTID Range Scanに、欠けていたEvalPlanQual再チェックが追加されました。  (Sophie Alpert, David Rowley) (17)(16)(15)(14)(13)</li>
<p>
この遺漏により、同時UPDATEでctid条件が再評価されない可能性があり、その時に選択されたプランタイプに応じて、UPDATEの振る舞いが変わる可能性がありました。
</p>
<p>
EvalPlanQual再チェックは主としてREAD COMMITTED隔離レベルの問い合わせで実行される内部処理です。ctidは現在の物理的なタプル位置をあらわすテーブルのシステム列です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0fb06e893">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ba0203880">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f00ad440a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f78a69034">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3d939a9b1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d6539f88b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=005770203">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2eb7ea97d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=940f3cd5d">&#167;</a></small></p>
<li>pg_event_trigger_dropped_objects()関数の戻り値のis_temporary列の挙動が修正されました。  (Antoine Violin, Tom Lane) (17)(16)(15)</li>
<p>
is_temporaryはオブジェクトが一時オブジェクトであるかどうかを示すものです。一時テーブルに属している列のデフォルト値、トリガ、RLS ポリシーが削除された場合にもtrueを返すように修正されました。このような場合にこれまでfalseを返していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c0c8ee23c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8856f1acc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=451373dc5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a220e40d1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f6c8e7824">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=33e49ee01">&#167;</a></small></p>
<li>ハッシュ化されたサブプラン(hashed SubPlan)でのメモリリークが修正されました。  (Haiyang Li) (17)(16)(15)(14)(13)</li>
<p>
タプルのハッシュの計算で使われた全てのメモリが問合せ終了まで残り続けるメモリリークとなっていました。一例として、ハッシュされる値がTOAST展開を要求する時にこの不具合が発生すると考えられます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=862980f92">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e1da9c072">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5ac973892">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5eab9b0a4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8b6c29afd">&#167;</a></small></p>
<li>スタンバイサーバの起動プロセスでのSMgrRelationオブジェクトのメモリリーク不具合が修正されました。  (Jingtang Zhang) (17)</li>
<p>
長時間実行されるスタンバイサーバでは、不要になったエントリを解放する処理がなかったため、これらのオブジェクトを保持するハッシュテーブルが大幅に肥大化する可能性がありました。
</p>
<p>
SMgrRelationはファイルハンドルを管理する実装コード内の構造体です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e2dd7b2ac">&#167;</a></small></p>
<li>メモリ不足エラー後に統計情報を管理する共有テーブルが破損する不具合が修正されました。  (Mikhail Kot) (17)(16)(15)</li>
<p>
新しいハッシュテーブルエントリの作成中にメモリ不足エラーが発生すると、壊れたエントリが残され、その後の他のセッションで予期せぬエラーやクラッシュが発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3e6dfcfb0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=12f57681c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1852ec5db">&#167;</a></small></p>
<li>MERGEにおける同時更新の問題が修正されました。  (Yugo Nagata) (17)(16)(15)</li>
<p>
MERGE UPDATE実行時に、対象行に対して複数の同時更新が発生した場合、ロックとリトライの処理が対象タプルの最新バージョンを誤って識別し、誤った結果を返すことがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6195afbe5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=21a61b87f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f871fbae9">&#167;</a></small></p>
<li>MERGEおよびINSERT ... ON CONFLICT DO UPDATEに不足しているレプリカアイデンティティチェックが追加されました。  (Zhijie Hou) (17)(16)(15)(14)(13)</li>
<p>
MERGEで更新または削除動作が必要になり、かつ更新または削除のターゲットテーブルが論理レプリケーションのパブリケーション対象である場合、そのテーブルにREPLICA IDENTITYが定義されている必要があります。これを必須としないと、レプリケーションが静かに中断される可能性があります。同様に、UPDATEオプション付きのINSERTでは、ターゲットテーブルが挿入または更新を発行するならばREPLICA IDENTITYが必須となります。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=76f45be93">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=421d7a157">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5481cc332">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0b934d399">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0c4d5a45d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=451b22efd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5fd569ef2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0610b843c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=57dfb64ec">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d37694b97">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a4624929d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ea65c8823">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dbef9cbaa">&#167;</a></small></p>
<li>パブリッシャがサブスクライバと同一サーバ上にある場合に発生するDROP SUBSCRIPTION実行時のデッドロックが回避されました。  (Dilip Kumar) (17)(16)(15)(14)(13)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=288a817bc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7ece76129">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e41137155">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ef7750274">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0a98f24a6">&#167;</a></small></p>
<li>通常のテーブルと一時テーブルとの間でファイル番号が偶然衝突することによる論理レプリケーションの失敗が回避されました。  (Vignesh C) (17)(16)(15)(14)(13)</li>
<p>
この発生確率の低い問題は、エラー「ERROR:  unexpected duplicate for tablespace X, relfilenode Y」のような一時的なエラーとして発生していました。contrib/autoprewarmも影響を受けていました。この修正の副作用として、SQL関数のpg_filenode_relation()は一時テーブルを無視するようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dcdc95cb4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ab874faaa">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ec471008c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=222130edd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=30b32b08c">&#167;</a></small></p>
<li>シングルユーザーモードでレプリケーションスロットを解放しようとする際のアサート失敗が回避されました。  (Hayato Kuroda) (17)(16)(15)(14)(13)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=07a302387">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fea1cc3f7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=818be9b73">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=32d388d00">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8ed079cad">&#167;</a></small></p>
<li>macOSおよびBSDプラットフォームで、既存のセマフォセットとの競合が発生した場合の起動失敗が回避されました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
既存のセットが要求したセマフォ数より少ない場合、これらのプラットフォームはコードが期待するEEXISTではなくEINVALを返すため、データベースの起動に失敗していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ab92f0e7f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e67d5f7ba">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f4c088344">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b3d6e8b63">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e3b3fa863">&#167;</a></small></p>
<li>libpqのトレース出力関数PQtrace()について、最上位ビットが設定された場合の出力が修正されました。  (Ran Benita) (17)(16)(15)(14)</li>
<p>
charが符号付きとみなされるプラットフォームでは、出力に余計な\xffffffが含まれていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0fedb3a27">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=701a0bd56">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0b274c475">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0cc540f0d">&#167;</a></small></p>
<li>pg_dumpでサブスクリプションとイベントトリガのセキュリティラベルがダンプされるようになりました。  (Jian He, Fujii Masao) (17)(16)(15)(14)(13)</li>
<p>
これらのオブジェクトタイプのラベルは、これまで除外されていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=968141898">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=20b23784f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=165b07efe">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=295c0a644">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dff7591a7">&#167;</a></small></p>
<li>pg_dumpのデフォルトACLと外部キー制約のソートが修正されました。  (Kirill Reshke, Álvaro Herrera) (17)(16)(15)(14)(13)</li>
<p>
他のオブジェクトタイプと同様に、これらのデータベースオブジェクトタイプの一貫した順序付けが確保されるようになりました。以前は順序が不安定であるほか、アサート失敗する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e8d22095e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e68fa9a83">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fbf967e99">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4948bb9df">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=05341b2e9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=49a09c6c5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=412d29fd2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=090c9c960">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=22c6a44f0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fb75e1ef7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=162e70ea0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7419c99a2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=06c1ee6b7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4cc3b4445">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6062c3db3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d20df9590">&#167;</a></small></p>
<li>pg_dumpで別々にダンプされたドメイン制約のコメントに、適切な依存関係を示すラベルが付与されるようになりました。  (Noah Misch) (17)(16)(15)(14)(13)</li>
<p>
以前は制約に対するコメントはドメインに依存させていました。このためpg_restoreを並列に実行した場合、 制約が復元される前にコメントの復元を試行してしまい、リストアが失敗する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e127764b6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3cf328eca">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0773f3a87">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=85d6ed31f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a685c057a">&#167;</a></small></p>
<li>pg_restoreでリストア対象外のパブリケーションおよびサブスクリプションのコメントとセキュリティラベルがスキップされるようになりました。  (Jian He, Fujii Masao) (17)(16)(15)(14)(13)</li>
<p>
--no-publicationsまたは--no-subscriptionsが指定されている場合、これらのオブジェクトに対するCOMMENTまたはSECURITY LABELコマンドは出力されません。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f7f9c5d65">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=97527a5e6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c8ed16050">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=db900ec35">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8fbd1f8ea">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dc8aa2f58">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0870397cc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5f42008f9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bc476f8b8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a4dbb11bb">&#167;</a></small></p>
<li>LLVMバージョン21以降でビルドが可能なように修正されました。  (Holger Hoffstätte) (17)(16)(15)(14)(13)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=755f01ad7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2670881af">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=72a24bebc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fbfc36e94">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=59d6e843e">&#167;</a></small></p>
<li>mesonでビルドする場合、makefileビルドと同様に特別な最適化フラグをnumeric.cとchecksum.cに適用するようになりました。  (Nathan Bossart, Jeff Davis) (17)(16)</li>
<p>
makefileが長年おこなってきたことと一致させるため、両ファイルで-ftree-vectorizeを使用し、checksum.cでは-funroll-loopsを使用します。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=15f9eeef6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=509c77929">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e25453a36">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2de24ca6c">&#167;</a></small></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 13.22 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/13-22/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Sun, 07 Sep 2025 23:30:03 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 13]]></category>
		<category><![CDATA[PostgreSQL 13.21]]></category>
		<category><![CDATA[PostgreSQL 13.22]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=18589</guid>

					<description><![CDATA[このリリースは 13.21 からの修正リリース（2025年 8月 14日リリース）です。 13.X からのアップデートではダンプ、リストアは不要です。 ただし、13.21 よりも前のバージョンからアップデートする場合には ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 13.21 からの修正リリース（2025年 8月 14日リリース）です。<br />
13.X からのアップデートではダンプ、リストアは不要です。</p>
<p>ただし、13.21 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/13-21/" rel="noopener">13.21のリリース情報</a>も参照してください。</p>
<p><span id="more-18589"></span></p>
<h3>PostgreSQL 13.21 から 13.22 への変更点</h3>
<p>17.6, 16.10, 15.14, 14.19, 13.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>プランナの見積もり関数におけるセキュリティチェックが強化されました。  (Dean Rasheed) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
CVE-2017-7484に対する修正およびその後の追加修正は、呼び出し元ユーザーに読み取り権限のない列の統計データに対して、情報漏洩の可能性がある関数が適用されるのを防ぐことを目的としていました。しかし、その対策には見落とされていた点が2つありました。
</p>
<p>
1つ目の見落としは、パーティションや継承階層に関するもので、テーブルに設定されたRLSポリシーが統計データへのアクセスを制限すべき状況で、実際には制限されていませんでした。
</p>
<p>
2つ目は、クエリがビューを介してテーブルにアクセスするケースです。この場合、ビューの所有者はビューの基になるテーブルの読み取り権限を持っていても、呼び出し元のユーザーがそのビューに対する権限を持っていないことがあります。これまでの実装では、ビューの所有者の権限がセキュリティチェックを通過させてしまい、その結果、呼び出し元ユーザーのビューに対する権限を確認する前に、基になるテーブルの統計情報に情報漏洩の可能性がある関数が適用されることがありました。この問題は、プランニングの開始時点でビューに対するセキュリティチェックを行うようにすることで修正されました。これにより、以前よりも早い段階で権限エラーが発生する可能性があります。(CVE-2025-8713)
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=64f77c6a6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a85eddab2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7e86da539">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=415badc13">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=afe38fb6a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=533211ded">&#167;</a></small></p>
<li>pg_dumpスクリプトが、リストアを実行するユーザーへの攻撃に使われるのが防止されました。  (Nathan Bossart) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
ダンプ／リストア操作では通常、SQLコマンドがスーパーユーザーとして実行されるため、ターゲットのデータベース環境は、ソースサーバーを信頼している必要があります。しかしそれは、リストアを実行するためにpsqlを使うOS上のユーザーが、ソースサーバーを信頼しなければならないことを意味するわけではありません。ここでのリスクは、攻撃者がソースサーバー上でスーパーユーザー権限を得ていた場合に、psqlのメタコマンドとして解釈されるようなテキストを出力させることができる点です。これにより、ターゲットデータベースへのアクセスとは無関係に、リストアを実行しているユーザーのアカウントに対し、シェルレベルのアクセスが可能になる恐れがあります。
</p>
<p>
このような事態が発生しないことを確実にするため、psqlに\restrictコマンドを追加し、それ以降のメタコマンドの実行を禁止できるようにしました。また、pg_dumpがソースサーバーからのデータよりも前にこのコマンドを出力するようにしました。(CVE-2025-8714)
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=67a2fbb8f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=575f54d4c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7ad8e7909">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=424040506">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e4998d089">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c204bd39f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8967c33c6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=27d3dee68">&#167;</a></small></p>
<li>pg_dumpの出力にあるコメント内の名前に含まれる改行がスペースに変換されるようになりました。  (Noah Misch) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
改行文字を含むオブジェクト名があると、出力スクリプト内に任意のSQLコマンドを挿入することが可能になってしまう問題がありました。（CVE-2025-8714の修正がなければ、psqlのメタコマンドをこの方法で注入することも可能でした。）この種の問題は、CVE-2012-0868によって過去に修正されていましたが、その後の開発によって、いくつかのケースが再び入り込んでしまっていました。(CVE-2025-8715)
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=13a67ce60">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9b92f115b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=850caae60">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9751f934a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0f5838438">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2179e6005">&#167;</a></small></p>
<li>BRINの組み込み演算子クラスnumeric_minmax_multi_opsが誤った距離計算をしてしまう問題が修正されました。  (Peter Eisentraut, Tom Lane) (17.6)(16.10)(15.14)(14.19)</li>
<p>
この関数の結果は、64ビット環境では時々誤りが生じ、32ビット環境では大きく誤った値を返すことがありました。ただし、このロジックはあくまで値をどのように範囲へ統合するかを決定するために使われているだけなので、明確なエラーとして現れることはありませんでした。最悪の場合でも、インデックスの効率が悪くなり、サイズが肥大化する程度です。それでも、numeric_minmax_multi_ops演算子クラスを使用しているBRINインデックスについては再インデックスを行うことが推奨されます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9b681e239">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0b0d3c19b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b9279058a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=835c9374d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5b0c8e328">&#167;</a></small></p>
<li>元々は存在しなかった受け入れ可能なXML入力サイズに関する上限がなくなりました。  (Michael Paquier, Erik Wienhold) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
libxml2の2.13系の初期リリースに存在したバグへの回避策として、10MBを超えるテキストチャンクを拒否するコードパスを使用していましたが、以前のコードではそのような制限はありませんでした。これら初期リリースは現在では実環境で使用されている可能性は低いため、以前のコードに戻しました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=637ead2e1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fd4ad33fe">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6d5e493b4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0ffbd345e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0395464af">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=589d6e640">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d5f014d89">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7571e0f6e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=762c6d8d2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0928e18eb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cdcdabce5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0ae824704">&#167;</a></small></p>
<li>同時更新によるMERGEの不具合が修正されました。  (Dean Rasheed) (17.6)</li>
<p>
MERGEがCTEの内部で実行され、かつ対象のテーブルにBEFORE ROWトリガが定義されている場合に、同時に別のUPDATEやDELETEによって対象行が変更されると、MERGEコマンドが失敗することがありました。具体的には、UPDATEの場合はクラッシュを引き起こし、DELETEの場合は誤ったアクションが実行される可能性がありました。
</p>
<p>
以下、DELETE実行で誤ったアクションが実行される実行例です。
</p>
<pre>
db1=# SELECT * FROM mergetbl;
 id | num | val
----+-----+------
  1 |  50 | init
(1 row)

(セッション1で上記のデータをUPDATE) 
db1=# BEGIN;
db1=*# UPDATE mergetbl SET num = 150, val = 'updated1' WHERE id = 1;
NOTICE:  UPDATE: (1,50,init) -> (1,150,updated1)

(セッション2から、CTEの内部からMERGEを実行する)
db1=# BEGIN;
db1=*# WITH m AS (
  MERGE INTO mergetbl m
  USING (SELECT 1 as id) s
  ON s.id = m.id
  WHEN MATCHED AND num < 100 THEN
    DELETE
  WHEN MATCHED AND num < 200 THEN
    UPDATE SET val = 'updated2'
  RETURNING *
)
SELECT * FROM m;

(セッション1を閉じる)
db1=*# COMMIT;

(セッション2で以下が返る)
NOTICE:  DELETE: (1,150,updated1)
 id | id | num | val
----+----+-----+------
  1 |  1 |  50 | init
(1 row)
→セッション1でnum = 150にしているので、正しくはUPDATEアクションが実行されるべき

(17.6では正しいアクションが実行される)
NOTICE:  UPDATE: (1,150,updated1) (1,150,updated2)
 id | id | num |   val
----+----+-----+----------
  1 |  1 | 150 | updated2
(1 row)
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=27c7c1136">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=91ad1bdef">&#167;</a></small></p>
<li>継承の親テーブルへのMERGEが修正されました。  (Dean Rasheed) (17.6)(16.10)(15.14)</li>
<p>
継承の親テーブルへの挿入は、WITH CHECK OPTIONおよびRETURNINGアクションの処理に失敗することで、クラッシュを引き起こしたり、不正確なクエリ結果を生成したりする可能性がありました。
</p>
<pre>
db1=# CREATE TABLE merge_parent (
  id int, value int);
db1=# CREATE TABLE merge_child () INHERITS (merge_parent);
db1=# CREATE VIEW merge_view WITH (security_barrier) AS
SELECT * FROM merge_parent WHERE value >= 0
WITH CHECK OPTION;

(17.5以前は、以下のようにエラーは返ってこず0行として返ってくる)
MERGE INTO merge_view tgt
USING (VALUES (2, -5)) AS src(id, value)
ON tgt.id = src.id
WHEN NOT MATCHED THEN
  INSERT (id, value) VALUES (src.id, src.value)
  RETURNING *;
 id | value | id | value
----+-------+----+-------
(0 rows)

MERGE 0

(17.6では以下のエラーが返ってくる)
ERROR:  new row violates check option for view "merge_view"
DETAIL:  Failing row contains (2, -5).
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ab52f6b5b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3611794af">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d6a3f3272">&#167;</a></small></p>
<li>文レベルのトリガを持つテーブルが、パーティションまたは継承の子テーブルになれるように修正されました。  (Etsuro Fujita) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
遷移テーブルを伴う行レベルのトリガは、パーティションや継承の子テーブルでは許可されていません。なぜなら、継承ツリー全体に対する操作では、各子テーブルごとに個別の遷移テーブルを管理しなければならないためです。しかし、この問題は文レベルのトリガには当てはまりません。文レベルのトリガは親テーブルのものだけが実行されるからです。それにもかかわらず、既存のテーブルがパーティションや継承の子テーブルになれるかを判断するコードは、両方の種類のトリガを一律に拒否していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bba6a6faf">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e028ce911">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3863c6fb6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f39a7f32a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=73eb6afa1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=afdb4cde1">&#167;</a></small></p>
<li>子テーブルである外部テーブルからの遷移タプルの収集を禁止するよう修正されました。  (Etsuro Fujita) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
PostgreSQLでは、外部テーブルに対して遷移テーブル付きのトリガはサポートされていません。しかし、パーティションや継承の子テーブルが外部テーブルである場合については、これまで見落とされていました。親テーブルに遷移テーブル付きのトリガがあると、外部テーブルである子テーブルから誤った遷移タプルが収集されてしまうことがありました。このようなケースはサポートされていないため、明示的に禁止するようにしました。この修正により、このような場合は、エラー「ERROR:  cannot collect transition tuplesfrom child foreign tables」が発生するようになりました。
</p>
<p>
以下に再現例を示します。
</p>
<pre>
(パーティションの子テーブルが外部テーブルである場合)
db1=# \d
                  List of relations
 Schema |     Name     |       Type        |  Owner
--------+--------------+-------------------+----------
 public | foreigntable | foreign table     | postgres
 public | parenttable  | partitioned table | postgres
(2 rows)

db1=# ALTER TABLE parenttable ATTACH PARTITION foreigntable FOR VALUES IN ('AAA');

(parenttable に対してAFTER INSERT 文レベルトリガ作成)
db1=# CREATE FUNCTION trigger_func() RETURNS trigger AS $$
BEGIN
  RAISE NOTICE 'trigger fired';
  RETURN NULL;
END;
$$ LANGUAGE plpgsql;

db1=# CREATE TRIGGER parenttable_insert_trig
  AFTER INSERT ON parenttable
  REFERENCING NEW TABLE AS new_table
  FOR EACH STATEMENT
  EXECUTE PROCEDURE trigger_func();

db1=# INSERT INTO parenttable VALUES ('AAA', 100);
ERROR:  cannot collect transition tuples from child foreign tables

(17.5 で実行するとエラーは発生しない)
db1=# INSERT INTO parenttable VALUES ('AAA', 100);
NOTICE:  trigger fired
INSERT 0 1
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ce8817022">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9048a83c7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9cca445df">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d642d2306">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e94fc1a8a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b6641f7b0">&#167;</a></small></p>
<li>予約済みプレフィックス付きの不明なカスタムパラメータのリセットを許可するようになりました。  (Nathan Bossart) (17.6)(16.10)(15.14)</li>
<p>
以前は、ALTER DATABASEやALTER ROLE、ALTER SYSTEMを使って保存されたパラメータ設定について、そのパラメータが不明なパラメータであっても、予約済みのプレフィックスを持っていた場合、その設定を削除することができませんでした。このようなケースは、拡張がかつて使用していたパラメータが、拡張のアップグレードで削除された場合などに発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7b9674a8b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=39ff05636">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b998ce327">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f79ca73d7">&#167;</a></small></p>
<li>ALTER SUBSCRIPTION ... DROP PUBLICATION実行時に発生しうるデッドロックが修正されました。  (Ajin Cherian) (17.6)(16.10)(15.14)(14.19)</li>
<p>
レプリケーションのオリジンを削除する時に、サーバープロセスがカタログロックを一貫した順序で取得するようにして、デッドロックの可能性を防ぐようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d9f01a287">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8c298324a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=adfd80219">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=434d2d147">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=41fb3f51c">&#167;</a></small></p>
<li>競合する名前を持つインデックスを作成する際に、競合状態となる時間が短縮されました。  (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
インデックスの自動生成名を決定する際、すでに有効なエントリとの競合と同様に、未コミットのエントリとの競合も回避するようになりました。これにより、他のトランザクションで並行してCREATE INDEXが実行されている場合に、まだインデックスの作成中であったり、作成は完了していてもトランザクションがコミットされていない場合に、同じインデックス名を誤って選んでしまう可能性を防げるようになりました。依然として競合が発生する可能性はありますが、これは新しいインデックスのパラメータを検証し、pg_classへの行挿入が完了するまでの短時間だけです。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fdd826922">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1e24ea160">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=75b8982ea">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=27af8b9be">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4b66cb188">&#167;</a></small></p>
<li>1つのコマンドで複数のテーブルをVACUUMする場合に、VACUUMオプションが間違って適用されてしまう問題が修正されました。  (Nathan Bossart, Michael Paquier) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
あるテーブルに対して指定されたTRUNCATE、INDEX_CLEANUPオプションが、他のテーブルにも誤って適用されてしまうことがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2e0b5d252">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d187cabdd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=354944663">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c079ba3fc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=65c3223f9">&#167;</a></small></p>
<li>インデックスのないテーブルをVACUUMする際に、そのテーブルの空き領域マップが適切なタイミングで更新されるようになりました。  (Masahiko Sawada) (17.6)</li>
<p>
以前の最適化により、そインデックスのないテーブルでは空き領域マップのVACUUM処理がスキップされてしまうことがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7c6ededac">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=792238c8b">&#167;</a></small></p>
<li>SIMILAR TO正規表現内の文字クラスの処理が修正されました。  (Laurenz Albe) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
SIMILAR TOパターンマッチング式をPOSIX形式の正規表現に変換するコードは、角括弧 [] がネストされ得ることを考慮していませんでした。例として、[[:alpha:]%_]というパターンでは、%と_の文字がリテラルとして扱われるべきですが、コードはそれらをメタ文字として扱っていました。
</p>
<pre>
(17.6では[[:digit:]%]で t が返る)
db=# SELECT '%' SIMILAR TO '[[:digit:]%]',
            '%' SIMILAR TO '[%[:digit:]]';
 ?column? | ?column?
----------+----------
 t        | t
(1 row)

(17.5では f が返る)
db=# SELECT '%' SIMILAR TO '[[:digit:]%]',
            '%' SIMILAR TO '[%[:digit:]]';
 ?column? | ?column?
----------+----------
 f        | t
(1 row)
</pre>
<p>
[%_[:alpha:]]のように前に%_を記述した場合は、修正以前も期待どおりの結果が返ってきていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e3ffc3e91">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e9e535d61">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b3e99115e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1fe15d25e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9481d1614">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a3c6d92f3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=52d08620e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4dc642e75">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0c09922c0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=31ee5ec69">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=54c05292b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=92a9ba3b9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=72fe74ca5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0420b24fe">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7ee00918f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a4da7b0cf">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=558ea446a">&#167;</a></small></p>
<li>pg_dumpなどでビューや関数の定義を取得するため、問い合わせを逆解析する際、「FETCH FIRST 式 ROWS WITH TIES」句の式部分を常に括弧で囲むように修正されました。  (Heikki Linnakangas) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
単純でない式は括弧で囲む必要がありますが、型キャスト付きの値などを誤って単純な式と見なし、括弧で囲まず、構文として誤ったSQLを生成する可能性がありました。
</p>
<pre>
(エラー発生例)
$ psql -c "CREATE VIEW v1 AS SELECT * FROM generate_series(1, 10) AS c1 ORDER BY c1 FETCH FIRST (5::bigint) ROWS WITH TIES;" db1
$ createdb db2
$ pg_dump db1 | psql db2
(省略)
ERROR:  syntax error at or near "::"
行 5:  FETCH FIRST (5)::bigint ROWS WITH TIES;
                      ^
</pre>
<li>checkpointerプロセスのfsyncリクエストキューのサイズを制限するように修正されました。  (Alexander Korotkov, Xuneng Zhou) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
shared_buffersの設定が非常に大きい場合、checkpointerプロセスがfsyncリクエストキューに1GBを越える領域を割り当てようとし、「invalid memory alloc request size」エラーが発生し、リトライを繰り返し、無限ループが発生していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bae507821">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=13559de95">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f0cdc2afd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b248a3ba4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=50026136c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f32a47161">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5cfbff48a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=605890034">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2ac50f118">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=73f897ba5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c5d66fc12">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7f872ae70">&#167;</a></small></p>
<li>ロジカルデコーディングで不完全なWALレコードの読み取り時に無限に待機し続けないように修正されました。  (Vignesh C) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
複数ページにまたがるWALレコードの最初の部分を書き込んだ後にサーバがクラッシュした場合、ロジカルデコーティングではWALストリームから次ページのデータが到着するのを待機します。しかし、データが到着することはなく、無限に待機し続けていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5449d5b7a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c9f4e7520">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b485e1c89">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9f270f48f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bedfdb85b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=762f352ca">&#167;</a></small></p>
<li>「MultiXactOffsetSLRU」と「MultiXactMemberSLRU」のLWLock待機イベント名の表記ゆれが修正されました。  (Bertrand Drouvot) (17.6)</li>
<p>
pg_wait_eventsとpg_stat_activityで待機イベント名が異なっており、これらのビューを結合する監視問い合わせが機能しない可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4fcbe06aa">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b3abec0ad">&#167;</a></small></p>
<li>pg_classのrelaclなど、データベースオブジェクトのアクセス権限を表す、ACL文字列内のロール名の引用符付けの一貫性のなさが修正されました。  (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
引用符の付け方はロケールに依存していたため、異なる環境に移行する際に移植性の問題が発生する可能性がありました。(pg_dumpではこの問題の影響はありませんが、他のツールでは影響する可能性があります。)一貫性を確保するため、出力時に非ASCII文字を常に引用符で囲むようになりました。ただし、下位互換性を維持するため、入力時に非ASCII文字を引用符で囲む必要はありません。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ccacaf4fa">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=50959f96e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=53a936b61">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=de73cb3ed">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ac8cdb249">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=093d3d745">&#167;</a></small></p>
<li>テーブルと外部テーブルのオプション名に等号 (=) を使用できないように修正されました。  (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
このようなオプション名に明確な使用例はなく、許容すると「name=value」という内部形式で格納する際に曖昧さが発生するため、使用できないように修正されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d4046125d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ab758ec4d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e76097124">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=eb4234647">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cd31eaaeb">&#167;</a></small></p>
<li>LZ4圧縮されたアーカイブデータの解凍が特定の条件下で失敗する問題が修正されました。  (Mikhail Gribkov) (17.6)(16.10)(15.14)</li>
<p>
この問題は圧縮率の低い入力データのみで発生するようで、これまで検出されなかった可能性があります。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d09d13793">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=074003431">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5c639523f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d44efe87e">&#167;</a></small></p>
<li>btreeインデックスのスキャン処理で稀にインデックスエントリを誤って削除済みとして扱ってしまう問題が修正されました。  (Peter Geoghegan) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
この問題は、マージ結合に伴うスキャンで、同じページに同時に挿入・削除されたエントリがある場合に発生する可能性があり、正しい行が取得できないことや不要なリソースが保持されることがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=40aa5ddea">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c7f25feb3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d2ec67109">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7c7c0a77d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=38c8d2987">&#167;</a></small></p>
<li>論理レプリケーションで他プロセスからのキャッシュ無効化メッセージを再送信しないように修正されました。  (vignesh C) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
以前のマイナーリリースでプロセス間のキャッシュ無効化メッセージに正しく応答するように修正され、更新適用中に古いカタログを参照しないようになりました。しかし、その際に意図せずメッセージを再送信してしまい、メッセージ数が急増し、メモリ割り当てエラーが発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=45c357e0e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b2ae07720">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fc0fb77c5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=983b36362">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1230be12f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=87819f766">&#167;</a></small></p>
<li>レプリケーションスロットの同期設定が誤っていても、サーバが予期せず停止しないように修正されました。  (Fujii Masao) (17.6)</li>
<p>
sync_replication_slotsがtrue、かつ、wal_levelがlogical未満の場合、postmasterプロセスはエラーを報告し、停止していました。本来の意図は単にスロット同期を無効にするだけのため、エラーメッセージのレベルを下げ、postmasterプロセスが停止しないようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2d81a246f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f71fa981c">&#167;</a></small></p>
<li>チェックポイント処理中の早過ぎる古いWALファイル削除が回避されました。  (Vitaly Davydov) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
チェックポイント処理中にレプリケーションスロットのリスタートポイントが進行すると、不要になったWALセグメントの早まった削除がなされ、その後すぐにデータベースがクラッシュした場合、リカバリに失敗する可能性がありました。 WALセグメントをチェックポイント1サイクル分、追加で保持するよう修正されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2090edc6f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cea8f2c3e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dd9bc1a17">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e2832bd96">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dd3df0b85">&#167;</a></small></p>
<li>レプリケーションスロットの確定済みフラッシュ位置を後方に移動しないようになりました。  (Shveta Malik) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
場合によっては、レプリケーションクライアントが永続的に保存したLSNよりも過去のLSNを確認し、再起動後に古いLSNを送信する可能性がありました。 クライアントが2つのポイント間のWALに対して何もする必要がないなら、これはバグとは言えません。ただし、データ重複を避けるため、そのWALを再送信すべきではありません。そのため、作成されたスロットに対しては常に最新の確認済みLSNを信頼するようになりました。
</p>
<p>
論理レプリケーションで予期せぬデータ重複コンフリクトが出る障害例が報告されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7318f241d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c0f51fde5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9d1a62359">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e68459489">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e323d9df0">&#167;</a></small></p>
<li>新しい論理レプリケーションワーカを起動する前に過剰な遅延が発生しないようになりました。  (Tom Lane) (17.6)(16.10)</li>
<p>
場合によっては、論理レプリケーションランチャーが新しいワーカを起動する前に、設定されたwal_retrieve_retry_intervalよりもかなり長い時間スリープすることがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9f33300e6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=87c8ed3db">&#167;</a></small></p>
<li>INSERT ... ON CONFLICTの論理レプリケーション中のメモリ解放後使用（use-after-free）が修正されました。  (Ethan Mertz, Michael Paquier) (17.6)(16.10)</li>
<p>
これにより、進捗状況の報告が不正確になる可能性があり、非常に運が悪ければ、wal senderプロセスがクラッシュする可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=11de339aa">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9e0b4b1ab">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ec96e8812">&#167;</a></small></p>
<li>スタンバイサーバでのトランザクション待機を中断できるようになりました。  (Kevin K Biju) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
スタンバイサーバでのレプリケーションスロットの作成には、プライマリサーバでのアクティブなトランザクションが終了し、その後スタンバイサーバでリプレイされるまで待機する必要がある場合がありました。これは無期限の待機となる可能性があるため、操作をキャンセルできるようにすることが望ましいのですが、ループ内でクエリのキャンセルがチェックされていませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=24c5ad5be">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=63fa7caa9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=405cca9da">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9130d8eee">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=706344f06">&#167;</a></small></p>
<li>物理レプリケーションのスタンバイサーバで動作する論理wal senderが、スタンバイサーバでリプレイ済のデータのみ送信するようになりました。  (Alexey Makhmutov) (17.6)(16.10)</li>
<p>
以前は未リプレイでもフラッシュ済のデータを送信しようとしていました。そのためにスタンバイサーバのシャットダウンに際して、startupプロセスが停止してWALリプレイがそれ以上進まないために、論理wal senderが無限に待機することがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=87be749c7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5e6d561bc">&#167;</a></small></p>
<li>自動VACUUMにおけるリレーションごとのメモリリークが修正されました。  (Tom Lane) (17.6)(16.10)(15.14)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cd3064f98">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e087b5b79">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=13d21b48a">&#167;</a></small></p>
<li>XMLSERIALIZE(... INDENT) でのセッション存続期間のメモリリークが修正されました。  (Dmitry Kovalenko, Tom Lane) (17.6)(16.10)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=075554ec6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=95cf1a181">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=abb517d61">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=20bae0690">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ee58de100">&#167;</a></small></p>
<li>「バンプ」アロケータを使用して大きなメモリブロックを割り当てる際、メモリ不足となった後に発生する可能性のあるクラッシュが修正されました。  (Tom Lane) (17.6)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a05cf22e0">&#167;</a></small></p>
<li>スナップショットなしでシステムカタログのTOASTされたフィールドを取得しようとする箇所が修正されました。  (Nathan Bossart) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
これにより、アサート失敗が発生したり、エラー「ERROR:  cannot fetch toast data without an active snapshot」が発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fe8ea7a2a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=24135398f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ddfcfb7ce">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b65be6ef0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b7ba2c030">&#167;</a></small></p>
<li>複数のテーブルまたがる制約がある場合に、制約を更新するとアサート失敗する問題が修正されました。  (Tom Lane, Jian He) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
例えば、アサートを有効にした環境では以下のクエリを実行するとアサート失敗が発生していました。
</p>
<pre>
(修正前のアサート失敗発生例)

=# CREATE TABLE t1(a int);
=# CREATE TABLE t2(b t1 CHECK ((b).a IS NOT NULL));
=# ALTER TABLE t1 ALTER COLUMN a TYPE numeric;
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bbfcbc4cd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c15798cf9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=614ffb26d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=25cab4473">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=13f1e9f26">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3d7a96871">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6d4395b40">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d36980b71">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e6dd6e6ee">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e902f8181">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f9ba071cc">&#167;</a></small></p>
<li>内部実装関数PortalRunMulti() の終了時点で必ずコマンドタグが決定されているとする誤ったアサートが削除されました。  (Álvaro Herrera) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
このアサートは、空のプリペアドステートメントの実行などの特殊なケースで失敗していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e0d3f3cfb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0c466f5e0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4871c1e9c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c2720ac60">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b9a896828">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=43cd85962">&#167;</a></small></p>
<li>XMLTABLEのパース処理でアサート失敗する問題が修正されました。  (Richard Guo) (17.6)(16.10)(15.14)</li>
<p>
XMLTABLE式では、列にNOT NULLを指定することが可能であり、これを表現するために、パーサーは内部的に「is_not_null」というオプション名を生成していました。しかし、パーサーはユーザーが任意のオプション名を指定できるようにもしているため、ユーザーが同名の「is_not_null」を明示的に使い、真偽値以外の値を割り当てた場合、内部の前提が崩れてアサートが失敗してしまう問題が発生していました。
</p>
<p>
今回の修正では、ユーザーが指定したオプション名が内部の予約名と衝突していないかをチェックし、衝突していた場合はエラーを出すようになりました。さらに、内部で使うオプション名を「__pg__is_not_null」に変更することで、ユーザー定義名との衝突リスクも低減されています。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2f48b4f07">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d3716d4b1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=666103090">&#167;</a></small></p>
<li>PL/pgSQLで式を並列実行できる機能が復元されました。  (Dipesh Dhameliya) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
この機能は以前は利用可能でしたが、過去のバグ修正によって意図せず無効化されてしまっていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=440c5ee20">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a553a2289">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3bbc1c4a7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c65c36ab5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=602c91cf2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ae693c0bf">&#167;</a></small></p>
<li>PL/Pythonにおけるエラー報告処理で発生する特殊なケースのメモリリークが修正されました。  (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
Pythonからのエラーを報告する際にメモリ不足が発生すると、Python オブジェクトの参照カウントを適切に減らす処理が失敗する可能性がありました。その結果、セッション全体にわたってメモリが解放されずに残存してしまう問題が起こることがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7559a16e2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5c7fd5976">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b56a92651">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=31a3a15fa">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1c78d5553">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6f724fcf8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ecc8fd2b7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b898bb2a7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d4556f592">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=93aca1246">&#167;</a></small></p>
<li>hostaddrを使ってサーバのアドレスを指定した場合に、libpqのPQcancelCreate()関数が正しく動作するよう修正されました。  (Sergei Kornilov) (17.6)</li>
<p>
これまではPQcancelCreate()が生成したキャンセル用のオブジェクトを実際に使用するとlibpq がセグメンテーション違反によりクラッシュする問題がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5d0800000">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=445bd37b1">&#167;</a></small></p>
<li>libpqのPQport()関数が修正され、引数として渡された接続がNULL でない限りこの関数はNULLを返さないようになりました。  (Daniele Varrazzo) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
これは仕様として文書化されていますが、バージョン10以降のlibpq ではユーザーがポートを指定しなかった場合にNULL を返すケースがありました。この挙動が仕様どおりに戻され、NULLを渡された場合には空文字列""を返すようになりました。 ただし、バージョン18以降では、コンパイル時に設定されたデフォルトのポート番号として、通常は5432が返されるようになります。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bfa9b25c9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3f10d2b66">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=009c20a3d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a372a64db">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d5cba7746">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9dcd1aa81">&#167;</a></small></p>
<li>GSSAPI認証で16kBを超えるパケットが必要な場合に、認証処理が失敗しないよう修正されました。  (Jacob Champion, Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
Active Directoryのグループに多数所属しているユーザーでは、より大きな認証パケットが必要ですが、16kBをパケットサイズの上限としていました。 この制限により、エラー 「GSSAPI context establishment error:The routine must be called again to complete its function: Unknownerror」などが発生し、接続が失敗するケースがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8b0aa7a6b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ca70ee6ed">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=39b1d1907">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a7da7914c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c81cdffa1">&#167;</a></small></p>
<li>SSLおよびGSSAPIによるデータ送信におけるタイミング依存の失敗が修正されました。  (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
SSLまたはGSSAPIでの暗号化をノンブロッキングモードで使用している場合、エラー「SSL error: bad length」または、エラー「GSSAPI callerfailed to retransmit all data needing to be retried」というメッセージを出力し、処理が失敗することがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=30e0d9ee9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3f37400cf">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6a4d93eda">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0703c9385">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f09fea386">&#167;</a></small></p>
<li>ECPGアプリケーションにおける接続の検索時に、NULLポインタ参照が発生しないよう修正されました。  (Aleksander Alekseev) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
この問題は、接続名がNULLの接続と非NULL接続少なくとも2つの接続が存在する状況で発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0ded7615d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2805e1c1e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=313d3102f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0123922f8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=408fe659a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c934d5673">&#167;</a></small></p>
<li>psqlのタブ補完がCOPYおよび\copy のオプションについて改善されました。  (Atsushi Torikoshi) (17.6)(16.10)(15.14)(14.19)</li>
<p>
COPY FROM とCOPY TOで同じオプションが提示されていましたが、これからは FROMかTO かを区別して、適したオプションだけ提示するようになります。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=765a4c94c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c1c6169eb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d69836b13">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e3584e457">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0514616f0">&#167;</a></small></p>
<li>pgbench で、複数のパイプライン同期メッセージを受けたときのアサート失敗が回避されました。  (Fujii Masao) (17.6)(16.10)(15.14)</li>
<p>
これはパイプラインモードを使用する場合の問題です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fee46ab4f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=398e07162">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1d3ded521">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6914a330f">&#167;</a></small></p>
<li>pg_createsubscriberコマンドでサブスクリプションを初期化するときの、トランザクションリプレイの重複が修正されました。  (Shlok Kyal) (17.6)</li>
<p>
サブスクライバのリカバリ中に処理された最後のトランザクションが、通常のレプリケーションが開始されたときに再送されてしまう可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=33f74b806">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=967309116">&#167;</a></small></p>
<li>pg_dumpがドメイン型におけるNOT NULL制約のコメントを確実にダンプするようになりました。  (Jian He, Alvaro Herrera) (17.6)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f9545e95c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6b755d8d7">&#167;</a></small></p>
<li>pg_dumpがドメイン型の制約のコメントを有効な順序で出力するようになりました。  (Jian He) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
これまで、制約を作成する前にそのコメントを付与するコマンドがあらわれる場合がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dca0e9693">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d07bc7c2b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cef998ef8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5a261c135">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e04aca1c4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=57949cea5">&#167;</a></small></p>
<li>全ての種類のデータベースオブジェクトについて、pg_dumpで安定したソート順を保つようになりました。  (Noah Misch, Andreas Karlsson) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
pg_dumpは依存性に基づく並び替えをする前に、オブジェクトをその論理名でソートしますが、ルールや制約などいくつかのオブジェクト種別については、OIDでのソートが行なわれており、論理的に同じデータベースで異なる出力順になる可能性がありました。このため、ダンプ出力を比較してオブジェクト差異を調べることが難しくなっていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c0ae03384">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1ca1889ea">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0ac1581c3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=22f126da6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7ee7c1cd3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=04bc2c42f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5dd4957b2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9affed263">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e99010cbd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=25388fb2c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cc9a62c51">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0d2734eac">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=28e7252e4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=216683296">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=70637d7ae">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7846f4709">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bc05590c7">&#167;</a></small></p>
<li>pg_dumpのフィルタファイルでオブジェクトタイプの誤った解析が修正されました。  (Fujii Masao) (17.6)</li>
<p>
キーワードとして次の空白文字までを解釈すべきところ、次にアルファベット、数字、アンダースコア以外の文字が現れるところまでを解釈していました。このため、「table_data」を誤って「table-data」と書いた場合にエラーにならずに「table」と解釈される、といった動作が生じていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e3764229e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7dafc4a41">&#167;</a></small></p>
<li>pg_restoreが、PostgreSQL 12より前のバージョンの pg_dumpで作られたディレクトリ形式のダンプからのラージオブジェクトのリストアにできない障害が修正されました。  (Pavel Stehule) (17.6)</li>
<pre>
（修正前のエラー発生例）
$ pg_restore -d db1 db1.d
pg_restore: error: could not open large object TOC file "db1.d/3210.dat" for input: No such file or directory
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=839802792">&#167;</a></small></p>
<li>pg_upgradeで一貫しない継承されたNOT NULL制約を検査するようになりました。  (Ali Akbar) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
PostgreSQL 18 より前のバージョンでは、継承された列のNOT NULL制約を除去できました。しかしながら、これはリストア不能な定義をもたらし、pg_upgradeが失敗しました。このような場合をpg_upgradeが事前検査で検出できるようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=07da2985d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b8b2e6052">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f63e408e8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0f4958685">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ea3386cc7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b0f0e2221">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1e007722f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bcb8d47cd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f943e2339">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bd48455d8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=94dc2b37b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=708469281">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1084e76f3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=930e1faec">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=05b367bea">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=63c79a6fc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a00eb374c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=160131033">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=22d783350">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f9f6595e3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7406a7d82">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=06f444816">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a8b31b160">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ed2bb0cdd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=de7fd83cd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=18d2d8ae4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bef2c2a4e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=095e83d09">&#167;</a></small></p>
<li>pg_upgrade でターゲットデータベースクラスタの postgresql.conf の max_slot_wal_keep_size に設定があるときエラーが発生していたものが、修正されました。  (Dilip Kumar) (17.6)</li>
<p>
これまではデフォルトの -1 であることが必要でした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f36e57745">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=24f6c1bd4">&#167;</a></small></p>
<li>initdb実行時に（すなわち-cで指定して）、track_commit_timestampが有効であるときのアサート失敗が回避されました。  (Hayato Kuroda, Andy Fan) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=29a4b63c6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ae20c105f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7e7059abf">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dcbbd4331">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b61ddcaf4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8bca4476f">&#167;</a></small></p>
<li>pg_waldumpが「PREPARE TRANSACTION」のWALレコードで、不正な情報（削除された統計）を表示していたものが、修正されました。  (Daniil Davydov) (17.6)(16.10)(15.14)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=11efaaffa">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0d2063585">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0e0174b49">&#167;</a></small></p>
<li>contrib/dblink の接続確立のときに接続リークの可能性があり、回避されました。  (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
新たな接続オブジェクトを作るときにout of memoryエラーを起こした場合に、オープンされたリモートサーバへの接続がローカルサーバへのセッションが終了するまでの間、リークして、リモートサーバ上でアイドルセッションが残りました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e20b3256a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8eef55db1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=09c9ae8f6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2cd2222ca">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e7d3d4ed4">&#167;</a></small></p>
<li>contrib/pg_prewarmで巨大なshared_buffers設定に対処できるようになりました。  (Daria Shanina) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
これまではshared_buffersがおよそ5000万ページ（400GB）を超えるとき、自動プレウォームでメモリ割り当てエラーが発生して動作しませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e4b8f925a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=169429264">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d59ff3be2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a4b9707c4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4adbaa36c">&#167;</a></small></p>
<li>contrib/pg_prewarm において、アサート失敗が発生しないよう修正されました。  (Masahiro Ikeda) (17.6)</li>
<p>
ストレージを持たないビューなどのリレーションに対してpg_prewarm()を実行すると、アサート付きビルドでは失敗していました。非アサートビルド時では実害はありませんでしたが、このようなケースをエラーとして拒否するよう修正されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b64c585fd">&#167;</a></small></p>
<li>contrib/pg_stat_statementsで、正規化されたクエリの$1、$2などのパラメータ番号に欠番が生じないよう修正されました。  (Sami Imseih) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<pre>
(欠番が発生する例)
=# SELECT WHERE '1' IN ('2'::int, '3'::int::text);
=# SELECT query from pg_stat_statements WHERE query LIKE '%SELECT WHERE%';
                            query
--------------------------------------------------------------
 SELECT WHERE $1 IN ($3::int, $4::int::text)
(1 row)
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=290e8ab32">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7e8b44f4e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=130300a15">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8a1459f62">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3c03b8cd7">&#167;</a></small></p>
<li>contrib/postgres_fdwのメモリリークが修正されました。  (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
DirectModifyメソッドの呼び出しの途中でクエリが失敗した場合に、リモート側の更新コマンドの結果を保持するPGresultがセッション終了まで解放されないメモリリークが発生していました。これはRETURNING句でデータを処理する際に起こる可能性がありました。
</p>
<p>
なお、DirectModifyメソッドとは外部テーブルにUPDATE等のDMLコマンドを実行できるようにする内部実装コードです。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9339c85af">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2b92dc4ee">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3c31594f5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4a07c0961">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=271cb7eaa">&#167;</a></small></p>
<li>configureの--with-includesおよび--with-librariesオプションで指定されたディレクトリが、システム標準ディレクトリよりも先に検索されるようになりました。  (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
これらのオプションを利用する一般的な理由は、ユーザがビルドしたライブラリをシステムが提供するライブラリより優先して使えるようにするためです。しかし、makefileが発行するコマンドのオプション順序が不適切だったため、一部の環境ではこの目的のために使えませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8e5e3ff55">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a644f5fc6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bbc20c8a9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=19857437b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2dee95bd0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c5bd803e5">&#167;</a></small></p>
<li>configureでの__cpuid()および__cpuidex()のチェックが修正されました。  (Lukas Fittl, Michael Paquier) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
これらのWindows固有の関数をconfigureが正しく検出できなかったために利用されず、ハードウェア命令の利用可否を確認できずにCRC計算が本来より遅くなる問題がありました。ただし、Windowsでの商用環境向けのビルドでは、通常はAutoconfツールチェーンを使用しないため、この不具合の影響は限定的です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cd2d52cc6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8de56323c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c1984be23">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d6ffc43f9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=60953d4cb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=612f5b806">&#167;</a></small></p>
<li>Solaris系プラットフォームで--with-pamオプションを指定した場合ビルドが失敗する問題が修正されました。  (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
Solarisでは、PAM認証のAPIが他のUNIX系プラットフォームと異なっており、その結果inconsistent pointerというコンパイラ警告が出力されていました。これまでは警告であるため対応されていませんでしたが、GCC 14以降では警告ではなくデフォルトでエラー扱いとなるため、修正されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3d039b53a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=635a85627">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e4d585455">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b252ce311">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=868b39a54">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1ccb3851d">&#167;</a></small></p>
<li>GNU Hurdへ移植できるようコードが修正されました。  (Michael Banck, Christoph Berg, Samuel Thibault) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
GNU Hurdでは、他のUnix系OSで一般的に定義されているIOV_MAXやO_RDONLYが存在しない点が考慮されていませんでした。IOV_MAXが未定義の場合には16とみなす旧来の処理を復活させるなど、GNU Hurd環境に対応する修正が行われました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=581305a46">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0991249d7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d25d392e8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=45c527662">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=29c54ea7b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3a2617e4f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0fb496c70">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=71d71ac4d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d0a695cf4">&#167;</a></small></p>
<li>memset_s()の使用をC11標準に厳密に準拠するよう修正されました。  (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
これにより一部のプラットフォームでのコンパイル失敗が回避されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5355a2400">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=253cf661c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4b53cb493">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=00652b3c9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a1e0e7076">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9bc2d37cc">&#167;</a></small></p>
<li>MSVCでMesonを利用してビルドする際に、互換性に関する警告が出力されていたものが修正されました。  (Peter Eisentraut) (17.6)(16.10)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2499c3490">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=629cc1623">&#167;</a></small></p>
<li>JSONBの比較を行う内部実装関数compareJsonbContainers()で、未初期化値に関するコンパイラ警告が出力されないよう修正されました。  (Tom Lane) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0b6dfce0c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5a2139a90">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5db55e13f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f32e45641">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8254b7e33">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6c93bf735">&#167;</a></small></p>
<li>libxml2 2.14以上を利用してビルドした際に、deprecatedである旨の警告が出力されていたものが、修正されました。  (Michael Paquier) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8d1071e7d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c911e7802">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d24a96ce2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=75c1eb60b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ac166b19a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e688cfc2b">&#167;</a></small></p>
<li>pg_locale.hをC++ でコンパイルする際の問題が修正されました。  (John Naylor) (17.6)(16.10)(15.14)(14.19)(13.22)</li>
<p>
PostgreSQLのヘッダファイルは、C++で書かれた拡張からインクルードできるように、通常は「extern "C" { ... }」 で囲む必要がありますが、pg_locale.hではlibicuのヘッダを使用しているためにこれが失敗していました。libicuヘッダ内のC++専用の宣言を利用しないようにすることで修正されました。
</p>
<p>
C++で書かれた拡張でlibicuのC++ API を利用したい場合は、pg_locale.hより前にlibicuのヘッダをインクルードする必要があります。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dd2926207">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=21ae8fc5f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=aae9aad19">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=baacfb9e6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a4f891b96">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9560c1ec1">&#167;</a></small></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 13.21 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/13-21/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Fri, 23 May 2025 00:00:44 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 13]]></category>
		<category><![CDATA[PostgreSQL 13.20]]></category>
		<category><![CDATA[PostgreSQL 13.21]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=17701</guid>

					<description><![CDATA[このリリースは 13.20 からの修正リリース（2025年 5月 8日リリース）です。 13.X からのアップデートではダンプ、リストアは不要です。 ただし、パーティションテーブルに自己参照の外部キー制約がある場合には、 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 13.20 からの修正リリース（2025年 5月 8日リリース）です。<br />
13.X からのアップデートではダンプ、リストアは不要です。</p>
<p>ただし、パーティションテーブルに自己参照の外部キー制約がある場合には、これらの制約を再作成する必要があります。下記の2番の項目を参照してください。</p>
<p>また、13.17 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/13-17/" rel="noopener">13.17のリリース情報</a>も参照してください。</p>
<p><span id="more-17701"></span></p>
<h3>PostgreSQL 13.20 から 13.21 への変更点</h3>
<p>17.5, 16.9, 15.13, 14.18, 13.21 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>不正にエンコードされた文字列の検査で、1バイトのバッファ超過読み取りが防止されました。  (Noah Misch, Andres Freund) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
文字エンコーディングGB18030であるものとして文字列を検査するときに発生します。可能性は低いですが、メモリの末尾で非互換のマルチバイト文字が現れた場合に、SIGSEGVのクラッシュが発生するおそれがあります。サーバとlibpqを用いたクライアントアプリケーションの両方で該当します。(CVE-2025-4207)
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ec5f89e8a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d1264948f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=44ba3f55f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3f2ab7393">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cbadeaca9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=617d34908">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f3bb0b2c4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=45fe7e08f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=258cde839">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7279e5820">&#167;</a></small></p>
<li>パーティションテーブルで自己参照の外部キーを正しく扱えるようになりました。  (Álvaro Herrera) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
制約に参照されたテーブルが同じパーティションテーブルであるとき、子パーティションを作成または付加するときに外部キー制約に対するカタログエントリの作成に失敗していました。この結果、制約が完全には強制されませんでした。これは12.13、13.9、14.6時点の修正で混入したバグです。
</p>
<p>
パーティションテーブル上に自己参照外部キー制約を作成した後に、子パーティションの作成や付加を行っていた場合、不適切なカタログ内容を修正するために、このような外部キー制約を削除して作成し直すべきです。制約に違反している行が既にあるかもしれず、そのような場合、制約の再作成はエラーになり、データ修正の対応が必要となることに、注意してください。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f51ae3187">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1817d62ec">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6ba979cf5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1649d153a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b3a9c536d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cb0ad70b8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ebcc799a7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e064b770c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6be02bbc8">&#167;</a></small></p>
<li>BRIN のサポートプロシージャ brin_bloom_union() で圧縮されたBRIN のサマリをマージするときにデータ損失を回避するように修正されました。  (Tomas Vondra) (17.5)(16.9)(15.13)(14.18)</li>
<p>
当該コードでは圧縮したものの展開結果が入力と同一でないことを考慮しておらず、インデックス検索をしたときに行数が少なく返り、誤った問い合わせ結果が生じる可能性がありました。
</p>
<p>
この誤りはBRIN bloomインデックスが導入されたv14時点から存在しましたが、当該のコードパスは使われることが稀でした。v17でパラレルインデックス作成が導入されて、問題が顕在化しやすくなりました。
</p>
<li>FROMのビューや関数に対する行全体のテーブル参照を使うUPDATE、DELETE、MERGEの問い合わせで、予期せぬエラー「ERROR:  attribute ... has wrong type」が生じることがあり、修正されました。  (Tom Lane) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<pre>
（エラー発生例）
db1=# CREATE TABLE t4 (f1 int, f2 int);
db1=# INSERT INTO t4 VALUES (1, 10), (2, 20), (3, 30);
db1=# CREATE VIEW v4 AS SELECT * FROM t4 OFFSET 0;
db1=# UPDATE t4 SET f2 = v4.f2 FROM v4 WHERE v4.f1 = t4.f1 RETURNING v4;
ERROR:  attribute 3 of type record has wrong type
DETAIL:  Table has type record, but query expects v4.
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ca0830e5a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fec43428c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ae0be2f0b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d3a29ae6a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=39af32f78">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=317aba70e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=584f17a90">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=28a7e31d0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7713f4592">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1a20bc946">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b200180de">&#167;</a></small></p>
<li>「DO NOTHING」アクションのパーティションテーブルに対するMERGEが修正されました。  (Tender Wang) (17.5)(16.9)(15.13)</li>
<p>
一部の場合に予期せぬエラー「ERROR:  unknown action in MERGE WHEN clause」が発生していました。
</p>
<pre>
（エラー発生例 - マッチしないので 1行挿入されるのが正しい動作）
db1=# CREATE TABLE pt5 (a int, b int) PARTITION BY LIST(a);
db1=# CREATE TABLE p51 PARTITION OF pt5 FOR VALUES IN (1);
db1=# CREATE TABLE p52 PARTITION OF pt5 FOR VALUES IN (2);
db1=# MERGE INTO pt5 USING (SELECT 2 AS a) AS q ON pt5.a = q.a
      WHEN NOT MATCHED THEN INSERT VALUES (1, 2)
      WHEN MATCHED THEN DO NOTHING;
ERROR:  unknown action in MERGE WHEN clause
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=25303678a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8d4cd3b4a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=14a33d3f0">&#167;</a></small></p>
<li>INSERTコマンドで、テーブルがNULLを禁止する制約を伴うドメインデータ型の生成列（GENERATED）を持つときのエラーが防止されました。  (Jian He) (17.5)(16.9)(15.13)(14.18)</li>
<p>
生成式が問題ない値を返す場合でも制約違反のエラーになっていました。
</p>
<pre>
（エラー発生例 - 値が NULL ではないのにドメイン制約違反のエラーになる）
db1=# CREATE DOMAIN d6 AS int CHECK (VALUE IS NOT NULL);
db1=# CREATE TABLE t6 (a int, b d6 GENERATED ALWAYS AS (a * 2) STORED);
db1=# INSERT INTO t6 (a) VALUES (2);
ERROR:  value for domain d6 violates check constraint "d6_check"
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3c39c000c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f04e0faa3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=97d671672">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4604928ed">&#167;</a></small></p>
<li>WITH句の内にあるINSERT、UPDATE、DELETE、MERGEコマンドに付加された外側のCTE名の参照を正しく扱えるようになりました。  (Tom Lane) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
このような場合にパーサは、再帰が許されない場合であることを検出できず、CTEを使用可能な順序に並べ替える際にそのような参照を考慮することもできませんでした。
</p>
<p>
本来エラーになるべき問い合わせで、何らか結果が返ったり、アサート失敗が生じる動作が報告されました。潜在的にはクラッシュを引き起こす可能性があります。
</p>
<pre>
（修正後の正常動作例 - このエラーが出ないというのがバグ）
db1=# CREATE TABLE t7 (id int);
db1=# INSERT INTO t7 VALUES (1),(2);
db1=# WITH RECURSIVE out_cte(n) AS 
      (WITH sub_cte AS (SELECT * FROM out_cte) DELETE FROM t7 RETURNING id)
      SELECT * FROM out_cte;
ERROR:  recursive query "out_cte" must not contain data-modifying statements
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5e7be43f4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1980ec2bc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ede29a1e4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=754a3d82d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e276b5829">&#167;</a></small></p>
<li>JSONコンストラクタ式のキーでのキャストの誤った処理が修正されました。  (Amit Langote) (17.5)</li>
<p>
以下のようにキーがjsonに暗黙キャストされる場合に、非スカラーのキーであることが検査されず、クラッシュを引き起こすことが報告されました。
</p>
<pre>
（修正後の動作例 - 最後のSELECTでクラッシュすることがあった）
db1=# CREATE TYPE typ8 AS ENUM ('happy', 'sad', 'neutral');
db1=# CREATE FUNCTION f8_to_json(typ8) RETURNS json LANGUAGE sql IMMUTABLE
        AS $$ SELECT to_json($1::text); $$;
db1=# CREATE CAST (typ8 AS json) WITH FUNCTION f8_to_json(typ8) AS IMPLICIT;
db1=# SELECT JSON_OBJECT('happy'::typ8 : '123'::jsonb);
ERROR:  key value must be scalar, not array, composite, or json
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8b2392ae3">&#167;</a></small></p>
<li>引数が無名レコード型であるとき、array_agg()の並列化を行わないようになりました。  (Richard Guo, Tom Lane) (17.5)(16.9)</li>
<p>
パラレルワーカーとの通信プロトコルでは、返されたレコードの型を特定することに対応していないためです。これまでパラレル実行時に「ERROR:  input of anonymous composite types is not implemented」が発生することがありました。
</p>
<pre>
（障害発生例 - 例でarray_dimsを使っているのは成功時の出力を小さくするため）
db1=# CREATE TABLE t9 (id int, v text);
db1=# INSERT INTO t9 SELECT g, md5(g::text) FROM generate_series(1, 400000) g;
db1=# VACUUM ANALYZE t9;
db1=# SET debug_parallel_query TO on;
db1=# SELECT array_dims(array_agg(s)) FROM (SELECT * FROM t9) s;
ERROR:  input of anonymous composite types is not implemented
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=43847dd5e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a7aa9f21f">&#167;</a></small></p>
<li>入力がint2vector型、またはoidvector型であるとき、配列コンストラクタのARRAY(subquery)とARRAY[expression, ...]が正常に配列を生成できるように修正されました。  (Tom Lane) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
以下のように、生成した配列をunnest関数に与えるとクラッシュが発生していました。
</p>
<pre>
（障害発生例 - oidv列を指定した場合も同様にクラッシュする）
db1=# CREATE TABLE t10 (i2v int2vector, oidv oidvector);
db1=# INSERT INTO t10 VALUES ('1', '10000');
db1=# SELECT ARRAY(SELECT i2v) FROM t10;
      array
------------------
 [1:1][0:0]={{1}}
(1 row)

db1=# SELECT unnest(ARRAY(SELECT i2v)) FROM t10;
server closed the connection unexpectedly
</pre>
<p>
この修正はPostgreSQL 9.5より前の振る舞いに戻すものです。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c826cd1b1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0405982c7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=13dd6f772">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f7ae51312">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=474aee3df">&#167;</a></small></p>
<li>Ispell辞書のパース時に、無効な接辞が誤って報告される可能性が修正されました。  (Jacob Brazeal) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=99c01aadf">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=61513da08">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e2921c0e9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=da85544ae">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f1c1bafcd">&#167;</a></small></p>
<li>デフォルトを持つドメイン型の場合を正しく処理するようにALTER TABLE ADD COLUMNが修正されました。  (Jian He, Tom Lane, Tender Wang) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
ドメイン型にデフォルトがある場合、（明示的なDEFAULT句を指定せずに）その型の列を追加すると、既存の行にドメインのデフォルト値が設定されず、新しい列はNULLのままになっていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d6dd2a02b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=edc3bccd0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1d180931c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c75c830e2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=aac07b562">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0941aadcd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=053222a97">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2d6cfb0cd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d31d39cfe">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dd34cbfce">&#167;</a></small></p>
<li>外部キー制約のON DELETE SET DEFAULTまたはSET NULLアクションで重複した列名がある場合の不正動作が修正されました。  (Tom Lane) (17.5)(16.9)(15.13)</li>
<p>
本障害でアサート失敗やメモリエラーが出る動作が報告されました。クラッシュを引き起こす可能性もあります。
</p>
<pre>
（報告された障害発生例）
db1=# CREATE TABLE t13 (c01 INT, c02 TEXT);
db1=# CREATE INDEX i13 ON t13 (c01);
db1=# INSERT INTO t13 (c01, c02) VALUES (0, 'abc');
db1=# CREATE LOCAL TEMP TABLE IF NOT EXISTS v878825600 ( c878825601 INT
  COMPRESSION DEFAULT CONSTRAINT cons_878825602 REFERENCES v878825600 MATCH
  SIMPLE ON UPDATE NO ACTION ON DELETE SET DEFAULT ( c878825601, c878825601,
  c878825601, c878825601, c878825601, c878825601, c878825601 ) PRIMARY KEY )
  ON COMMIT DELETE ROWS;
db1=# CREATE LOCAL TEMP TABLE IF NOT EXISTS v878825601 ( c878825601 INT
  COMPRESSION DEFAULT CONSTRAINT cons_878825602 REFERENCES v878825600 MATCH
  SIMPLE ON UPDATE NO ACTION ON DELETE SET DEFAULT ( c878825601, c878825601,
  c878825601, c878825601, c878825601, c878825601, c878825601 ) PRIMARY KEY )
  ON COMMIT DELETE ROWS;
ERROR:  pfree called with invalid pointer 0x103e61f (header 0x0000006000000001)
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5e6e97fbf">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fb3a77fd9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f5069f026">&#167;</a></small></p>
<li>外部キー制約のプロパティ変更が許可されなかった場合のエラーメッセージが改善されました。  (Álvaro Herrera) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<pre>
（報告された不適切なエラーメッセージ）
db1=# CREATE TABLE pk14 (a int PRIMARY KEY);
db1=# CREATE TABLE fk14 (a int REFERENCES pk14);
db1=# ALTER TABLE fk14 ALTER CONSTRAINT fk14_a_fkey DEFERRABLE,
      ALTER CONSTRAINT fk14_a_fkey NO INHERIT;
ERROR:  ALTER CONSTRAINT statement constraints cannot be marked NO INHERIT

（本来出力されるべきエラーメッセージ）
ERROR:  FOREIGN KEY constraints cannot be marked NO INHERIT
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4e026be5f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9ea5fe5b6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bf1e2d2db">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=931a1c023">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0f354e080">&#167;</a></small></p>
<li>ON COMMIT DELETE ROWSとマークされた一時テーブルのrelhassubclassフラグをリセットする際のエラーが回避されました。  (Noah Misch) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<pre>
（報告されたエラー発生例）
db1=# CREATE TEMPORARY TABLE p15 (a int PRIMARY KEY) ON COMMIT DELETE ROWS;
db1=# CREATE TEMPORARY TABLE c15 () INHERITS (p15);
db1=# ANALYZE;
db1=# DROP TABLE c15;
db1=# ANALYZE;
ERROR:  tuple to be updated was already modified by an operation triggered by the current command
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d0a049987">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5905e9935">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e0f53e669">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a61b67cd0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d34b671a6">&#167;</a></small></p>
<li>XMLSERIALIZE()のINDENTオプションで不足していた逆解析が追加されました。  (Jim Jones) (17.5)(16.9)</li>
<p>
以前は、XMLSERIALIZE(... INDENT)を使用するビューまたはルールがINDENT句なしでダンプされ、リストア後に誤った問い合わせ結果が発生していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2e0f93d7c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0af3ae468">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=310907aaf">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=514d47dfb">&#167;</a></small></p>
<li>FILTERオプションとORDER BY（またはDISTINCT）の両方のオプションを持つ集約関数の引数を早期評価しないようになりました。  (David Rowley) (17.5)(16.9)</li>
<p>
ORDER BYまたはDISTINCTが指定されている場合、Aggプランノード内でソートを行うのではなく、集約入力値を事前にソートすることを検討します。しかし、集約入力に失敗する可能性のある式（例えば、入力の除数の一部が0になる可能性がある除算など）が含まれ、そのような失敗を防ぐためのFILTER句がある場合、これは問題となります。事前にソートすると、式の評価がFILTERテストの前に押し出され、いずれにせよエラーが発生する可能性があります。FILTERがあり、入力式が単純なVarやConstよりも複雑なものである場合は、事前ソートを行わないようにすることで、これを回避するようになりました。
</p>
<pre>
（報告された障害発生例）
db1=# CREATE TABLE t17 (id int, data jsonb);
db1=# INSERT INTO t17 (id, data) VALUES
      (1,'{"a": null}'), (2,'{"a": "2"}'), (3,'{"a": "2"}'), (4,'{"a": ""}');
db1=# SELECT array_agg(distinct (data->>'a')::int)
        FILTER (WHERE data->>'a' IS NOT NULL AND data->>'a' != '') FROM t17;
ERROR:  invalid input syntax for type integer: ""
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=065ce49a1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=887a23237">&#167;</a></small></p>
<li>外部結合が存在する場合のNOT NULL制約列からの誤った推論が修正されました。  (Richard Guo) (17.5)</li>
<p>
外部結合の後に適用されるので冗長ではない（外部結合で NULL が生じうる）にもかかわらず、場合によってはプランナが問い合わせ条件「IS NOT NULL」を破棄していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bc5a08af3">&#167;</a></small></p>
<li>複合型の値に適用される「IS [NOT] NULL」テストに基づく誤った最適化が回避されました。  (Bruce Momjian) (17.5)</li>
<p>
要素がNULLである複合型の値は、NOT NULL制約では排除されませんが、IS NULL／IS NOT NULL式ではNULLとして扱われます。そうではない一貫性に欠けた振る舞いがあり、誤った問い合わせ結果が生じていました。ドキュメントにも複合型についてはNOT NULL制約とCHECK (VALUE IS NOT NULL)制約は同じでは無いことが明記されました。
</p>
<pre>
（修正前バージョンでの誤動作例 - id=1 の行のみ選択されるのが正しい動作）
db1=# CREATE TYPE typ19 AS (m1 int, m2 int);
db1=# CREATE TABLE t19 (id int, v typ19 NOT NULL);
db1=# INSERT INTO t19 VALUES (1, '(10,20)'), (2, '(,)');
db1=# SELECT id, v, (v IS NULL) AS isnull FROM t19 WHERE v IS NOT NULL;
 id |    v    | isnull
----+---------+--------
  1 | (10,20) | f
  2 | (,)     | t
(2 rows)
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b8b1e87b7">&#167;</a></small></p>
<li>プランナがトップレベルの式内で複数のハッシュ可能なScalarArrayOpExpr部分式を認識できない問題が修正されました。  (David Geier) (17.5)(16.9)(15.13)(14.18)</li>
<p>
この結果、ハッシュテーブルで処理できるはずの追加の部分式（すなわち、右辺が全て定数のIN、NOT IN、= ANY）が不必要に非効率的に実行されることがありました。
</p>
<p>
内部でハッシュテーブルを使うかどうかはEXPLAINの出力には現れませんが本修正で性能改善が期待できます。以下のような形状の問い合わせが該当します。
</p>
<pre>
SELECT * FROM t20
  WHERE c1 IN ('certainstring1', 'certainstring3', 《...多数の項...》)
     OR c1 IN ('certainstring2', 'certainstring4', 《...多数の項...》);
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5672a8399">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5a0840b76">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a7f213b11">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b68f664bb">&#167;</a></small></p>
<li>低いfillfactor設定値による誤ったテーブルサイズの推定値が修正されました。  (Tomas Vondra) (17.5)</li>
<p>
まだANALYZEが実行されていないテーブルの行数をプランナが推定する時、テーブルのfillfactor設定を推定に使用しますが、その結果を少なくとも1ページあたり1行に制限する処理が省略されていました。fillfactorの値が低い場合、推定値が不当に小さくなる可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=587b6aa3f">&#167;</a></small></p>
<li>Bitmap Heap Scanにおけるskip fetch最適化が無効になりました。  (Matthias van de Meent) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
この最適化を使用すると、並行して実行されるVACUUM処理がページをall-visibleとマークした時に、デッドタプルが返されることがあることが判明しました。これにより誤った問い合わせ結果が生じる可能性があります。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=78cb2466f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=980727b84">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=77d90d6d6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4934d3875">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b9ec8125d">&#167;</a></small></p>
<li>多数の検索キーがある場合のGINインデックス検索起動時の性能問題が修正されました。  (Tom Lane, Vinod Sridharan) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
多くのキーを持つインデックス可能な句（例えば、配列要素が数万個ある「jsonbcol ?| array[...]」）は、クエリの開始に O(N2) の時間を要しており、またその処理中にキャンセルもできませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9094eb25b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d52221cf0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2d313375c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e2a6934a8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=308d0d443">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8c153fcfa">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4b65b085a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9a8c16aec">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1b47a112a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c7597a1d3">&#167;</a></small></p>
<li>BRINインデックスの演算子クラスでサポートされてないプロシージャを検出して、エラーが報告されるようになりました。 (Álvaro Herrera) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>これまでクラッシュが生じていました。</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ade976f8b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e0d8f49a3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5d8c58800">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5144e1f8f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f5b4a0b49">&#167;</a>
</p>
<p></small></p>
<li>Appendプランノードの非同期サブプランの待機中に、クエリキャンセルなどの割り込みに応答できるようになりました。  (Heikki Linnakangas) (17.5)(16.9)(15.13)(14.18)</li>
<p>
以前の動作では、サブプランのいずれかが準備完了するまで何も処理されませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e731e9d5e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=004dbbd72">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d4d34c08c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d2fb076be">&#167;</a>
</p>
<p></small></p>
<li>稼働中のwal senderのI/O統計をより高頻度に報告するようになりました。  (Bertrand Drouvot) (17.5)(16.9)</li>
<p>
これまでは、pg_stat_ioビューはwal senderによるI/O実行をプロセス終了まで集計していませんでした。 これからはそのようなI/Oも最大1秒遅れで報告されます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5cbbe70a9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e2a82cd23">&#167;</a></small></p>
<li>起動直後のsynchronous_standby_names設定の扱いについて、競合状態が修正されました。  (Melnikov Maksim, Michael Paquier) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
起動後の短時間において、synchronous_standby_namesが有効であるのに、バックエンドプロセスが同期コミットを待機しない場合があり得ました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3339847cc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c922ae2c4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ec59500a1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=873aff945">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e2f42f812">&#167;</a></small></p>
<li>問い合わせ内での設定パラメータio_combine_limitの変更が有効になりました。  (Thomas Munro) (17.5)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e27346807">&#167;</a></small></p>
<li>設定パラメータscram_iterationsがINT_MAX（2147483647）に設定されている場合の無限ループが回避されました。  (Kevin K Biju) (17.5)(16.9)</li>
<p>
「ALTER ROLE role1 WITH PASSWORD 'pass'」などで応答がなくなります。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=34fbfe1f5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=de1484736">&#167;</a></small></p>
<li>json_array()関数の副問い合わせの二重変換によりクラッシュを起こす可能性があり、回避されました。  (Tom Lane) (17.5)(16.9)</li>
<p>
json_array()関数にWITH句を伴う問い合わせを渡した場合にアサート失敗や予期せぬエラーが生じる動作が報告されました。
</p>
<pre>
（エラー発生例）
db1=# SELECT json_array( WITH x AS (SELECT 1) VALUES (TRUE) );
ERROR:  unexpected utility statement in WITH

（修正後バージョンでの出力）
 json_array
------------
 [true]
(1 row)
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=717e8a1e5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ca54f9b70">&#167;</a></small></p>
<li>内部関数pg_strtof()の引数endptrがNULLの場合にクラッシュする問題が修正されました。  (Alexander Lakhin, Tom Lane) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
引数endptrにNULLが指定されているコードはリリース済のPostgreSQLには存在しないので、通常影響はありません。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d69c78108">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5c64ece8a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c7303f01c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=76fbb38ef">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ebe919e95">&#167;</a></small></p>
<li>GUCパラメータの一部設定において、メモリ不足発生後にクラッシュする問題が修正されました。  (Daniel Gustafsson) (17.5)(16.9)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8afec4ef6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8d48e84c5">&#167;</a></small></p>
<li>Snowball語幹処理でメモリ不足が発生した場合にクラッシュする問題が修正されました。  (Maksim Korotkov) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7edd2cbc5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c0c364fa1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9c46d902b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8388cae55">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=197427fb3">&#167;</a></small></p>
<li>実行計画作成時に、メモリ解放してはいけないSpecialJoinInfo構造体まで解放してしまう問題が修正されました。  (Richard Guo) (17.5)</li>
<p>
これにより、パーティションワイズ結合が有効な場合に、クラッシュすることがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=727bc6ac3">&#167;</a></small></p>
<li>無効化済のレプリケーションスロットがコピーできないようになりました。  (Shlok Kyal) (17.5)(16.9)</li>
<p>
これまでは、削除済みのWALを指している無効なスロットをコピーできてしまい、意図しないエラーやデータ破損につながる可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a4309e85f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=87e8599e0">&#167;</a></small></p>
<li>ホットスタンバイではないスタンバイサーバ上で論理レプリケーションスロットをリストアできないようになりました。  (Masahiko Sawada) (17.5)(16.9)</li>
<p>
wal_levelがlogicalより低く設定されていると、スロットが有効なまま残り、昇格後にアサート失敗する可能性がありました。
</p>
<p>
ここでの「リストア」はPostgreSQLサービス起動時にファイルに記録されていたスロットを読み込んで有効化することを指します。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=174952ece">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cc628f661">&#167;</a></small></p>
<li>論理デコーディングでデコーディング位置を指定の位置まで進める処理で、レプリケーションスロットのcatalog_xminが過剰に進められてしまう問題が修正されました。  (Zhijie Hou) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
本来WAL読取処理に必要なはずのカタログ情報がVACUUMで削除され、誤動作やデータの不整合を引き起こす可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=36148b22e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=21a7caeeb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f6429bd7d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1f63b3626">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d65485b02">&#167;</a></small></p>
<li>強いロックを取らないDDL操作が論理レプリケーションの対象テーブルである場合にデータ破損を起こす可能性があり、修正されました。  (Shlok Kyal, Hayato Kuroda) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
ALTER PUBLICATION ADD TABLEやALTER TYPEなど、強いロックを取らないDDLによりカタログが更新された場合、WALをデコードする処理がその情報を取得できず、古いカタログ情報を使ってデコードしてしまうことで、結果としてデータが破損してしまう可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cadaf0ac4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9a2f8b4f0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9f21be08e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0434033e8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=247ee9415">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d96206f25">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9987c9466">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=90bc4523f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bb1bc9fa9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4164d6976">&#167;</a></small></p>
<li>apply workerがエラーに遭遇したものの、PL/pgSQLの関数などでエラー処理された場合に、レプリケーションオリジンを誤ってリセットする問題が修正されました。  (Hayato Kuroda) (17.5)(16.9)</li>
<p>
この結果、同じデータが再度適用されデータが重複してしまうことがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=05676d87e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0de091a4b">&#167;</a></small></p>
<li>サブスクライバ側のパーティションテーブルにBRINインデックスが存在する場合に、論理レプリケーションのapply workerプロセスがクラッシュすることがあり、修正されました。  (Tom Lane) (17.5)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=788baa9a2">&#167;</a></small></p>
<li>論理レプリケーションのインデックス検索で重複したスナップショットの作成を回避するようになりました。  (Heikki Linnakangas) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>この誤りによる実害はありません。</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c1dd3a944">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8171d2dae">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=50c589992">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2ef048855">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9b3914f18">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f1ef111a0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=324e0b656">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d765226cb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=136e68b46">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6c1e79589">&#167;</a></small></p>
<li>サブスクリプション作成時に、オリジンが混在している場合の検知が改良されました。  (Hou Zhijie, Shlok Kyal) (17.5)(16.9)</li>
<p>
サブスクリプション作成時に、サブスクライブ先のテーブルが他のパブリケーションを追随している場合、重複したデータの受信につながる可能性があるため、警告が表示されます。今回の変更では、パーティションの親テーブルまたは子テーブルが別のパブリケーションを追随している場合も警告が出力されるようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0ae1245e0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1c2a2354c">&#167;</a></small></p>
<li>リカバリタイムラインの選択が不適切である場合、エラーメッセージに誤ったチェックポイントに関する情報が出力されていましたが、修正されました。  (David Steele) (17.5)(16.9)(15.13)</li>
<p>
要求されたリカバリタイムラインに到達できない場合、報告されるチェックポイントとタイムラインは、存在する場合、backup_labelから読み取られた値になります。このメッセージは以前はpg_controlファイルから値を報告していましたが、これはbackup_labelのない制御ファイルからリカバリする場合は正しいのですが、backup_labelがある場合には正しくありませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=29cce279b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b4969a296">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=62bed7bb0">&#167;</a></small></p>
<li>smgropen()内の操作順序が修正されました。  (Andres Freund) (17.5)</li>
<p>
smgr_openコールバックを呼び出す前にSMgrRelationオブジェクトが完全に初期化されていることを確認するようになりました。これにより、コールバックが失敗した場合でも適切にクリーンアップされます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ee578921b">&#167;</a></small></p>
<li>pgstat_report_stat()内の誤ったアサートが削除されました。  (Michael Paquier) (17.5)(16.9)(15.13)</li>
<p>
pgstat_report_stat()は、実行中のプロセスが自身の統計情報を定期的にサーバに報告するための関数です。特にPostgreSQL 16以降では、WAL senderは定期的に自身のI/O統計情報を報告するようになりましたが、このレポート処理が、他の状況で発生する可能性のあるpgstat_report_stat()の呼び出しと競合するケースが発生しました。また、非常に稀ではありますが、15.xでもバックグラウンドワーカーなどのプロセスによるpgstat_report_stat()の同時呼び出しによって同様の競合が引き起こされる可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4b6331e0f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e9ab8677b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c1201ffcf">&#167;</a></small></p>
<li>gistFindCorrectParent()の過度に厳密なアサートが修正されました。  (Heikki Linnakangas) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6526d0794">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=419321398">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3c0fe75c4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a749c6f18">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b92482dc3">&#167;</a></small></p>
<li>maintenance_work_memの値が非常に小さい場合、並列バキュームでのアサート失敗が回避されるようになりました。  (Masahiko Sawada) (17.5)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a38dce3c4">&#167;</a></small></p>
<li>プライマリサーバの再起動時にスタンバイサーバで稀に発生するアサート失敗が修正されました。  (Heikki Linnakangas) (17.5)(16.9)(15.13)(14.18)</li>
<p>
内部関数が、古いトランザクションを「実行中でなくなった」とマークする際に、トランザクションの実行状況に関する変数を更新しておらず、ホットスタンバイ中にアサート失敗が発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=302ce5bd9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2f33de3cd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b30c77a0e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=66235baab">&#167;</a></small></p>
<li>PL/pgSQLで、単純なSELECT式クエリでスクロール可能なカーソルが定義されている場合に発生するエラー「ERROR:  unexpected plan node type」を回避するようになりました。  (Andrei Lepikhov) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1353b1161">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a28c1fb61">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5e56efa7c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c196c610b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0f60e1fba">&#167;</a></small></p>
<li>pg_dumpの--cleanモードで、個々のインデックスパーティションを削除しようとしないようになりました。  (Jian He) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
サーバはこのようなDROPコマンドを拒否します。パーティションは、親テーブルまたはパーティションインデックスのいずれかの後続のDROPで、いずれにせよ削除されるため、実際には何の影響もありません。ただし、エラーは発生するため、psqlの--single-transactionモードでリストアする際にはリストアのトランザクション全体が失敗するため、問題を引き起こしました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3424c1075">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a25f21d99">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7144cd538">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=148cc0105">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6a3e57865">&#167;</a></small></p>
<li>pg_dumpallにおいて、pg_auth_membersに無効なロールのOIDが含まれている場合、無効なロールに対するGRANTコマンドが出力されないようになりました。  (Tom Lane) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
代わりに警告を出して該当エントリをスキップするようになりました。これは、GRANTとDROP ROLEが競合するタイミングで発生する可能性があったカタログ破損への対策です。過去のバージョンではこのような破損が確認されていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=16eff4261">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d850a6600">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6df3be415">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ce1475acd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5302ff95c">&#167;</a></small></p>
<li>pg_amcheckおよびpg_upgradeにおいて、libpqが確保したメモリを解放する際に正しい関数が使用されるようになりました。  (Michael Paquier, Ranier Vilela) (17.5)(16.9)(15.13)(14.18)</li>
<p>
これまで、Windows環境の特定のビルド構成、たとえばlibpqがデバッグビルドで、それを使用するアプリケーションが非デバッグビルドである場合などに、クラッシュが発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ee78823ff">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9ca2145b0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0851b6573">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=57467ec7b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f903d4da9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=816149dc6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ec741d480">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=35a591a04">&#167;</a></small></p>
<li>reindexdbコマンドの並列リインデックス処理におけるスケジューリング  (Alexander Korotkov) (17.5)</li>
<p>の問題が修正されました。従来は、指定した並列数にならない場合がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=09ef2f8df">&#167;</a></small></p>
<li>contrib/pageinspectのheap_page_items()関数において、破損したページを読み込んでもクラッシュしないようになりました。  (Dmitry Kovalenko) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ecb8e5641">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2d33cf7b8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=90a3fd811">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3c2ea65bd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3f9132ed2">&#167;</a></small></p>
<li>contrib/pg_freespacemapのpg_freespacemap()関数が、ビューなどストレージを持たないリレーションを指定するとアサート失敗する問題が修正されました。  (Tender Wang) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
このような対象を指定した場合は、エラーとして拒否されるようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=51d038da8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=41ed749e4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0e86bad38">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5ff827389">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=db8238da4">&#167;</a></small></p>
<li>contrib/postgres_fdwで、サブクエリからの制限条件を引き出さないようになりました。  (Alexander Pyhalov) (17.5)</li>
<p>
この修正により、稀に発生するエラー「ERROR: expected expression in subquery output」が回避されます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=729fe699e">&#167;</a></small></p>
<li>システムのインクルードディレクトリに古いバージョンのlibpq_fe.hが存在する場合にビルドが失敗する問題が修正されました。  (Tom Lane) (17.5)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f186f90e5">&#167;</a></small></p>
<li>macOS 15.4でビルドが失敗する問題が修正されました。  (Tom Lane, Peter Eisentraut) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
このmacOSアップデートにより、strchrnul()関数の設定プローブが機能しなくなっていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=915e88968">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a39eb9c77">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0de9560ba">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=71790aef1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e4440a73c">&#167;</a></small></p>
<li>読み込みストリームのバッファ単位データのvalgrindラベル付けが修正されました。  (Thomas Munro) (17.5)</li>
<p>
これはPostgreSQLのリリース版のコアコードには影響しませんが、バッファ単位のデータ機能を使用する拡張がvalgrindでのテスト中に誤ったエラーが発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=57dca6faa">&#167;</a></small></p>
<li>文字列ハッシュコードに関するvalgrindの警告がでないようになりました。  (John Naylor) (17.5)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fde7c0164">&#167;</a></small></p>
<li>タイムゾーンデータファイルが tzdata release 2025b に更新されました。  (Tom Lane) (17.5)(16.9)(15.13)(14.18)(13.21)</li>
<p>
中国の夏時間法の変更とイランの歴史的修正が含まれます。また、チリのアイセン州のタイムゾーンが年間を通じて UTF-03 に変更されてAmerica/Santiago から分離したため、新たに America/Coyhaique が追加されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5d5970b9f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e076120d9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a144cf145">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fa4244a43">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9da548df3">&#167;</a></small></p>
<li>contrib/dblinkの問い合わせがキャンセルできるようになりました。  (Noah Misch) (16.9)(15.13)(14.18)(13.21)</li>
<p>
これは17.xバージョンむけの変更の後方適用です。デッドロック検出の失敗のためにCREATE DATABASEとDROP DATABASEで起こりうるハングアップを防止します。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=82a8f0f46">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=63f6ecb6b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a8a918937">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=186c586c3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9e129a224">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=aa435d7c4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5a3d5c083">&#167;</a></small></p>
<li>スナップショット作成で起きるアサート失敗が修正されました。  (Masahiko Sawada) (15.13)(14.18)</li>
<p>
ロジカルレプリケーションで問題が報告されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0f404c581">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7be51eb4e">&#167;</a></small></p>
<li>アーカイブからリストアされたWALファイルの破損を防ぐため、アーカイブリカバリ時にはWALファイルの再利用と事前割り当てを行わないようになりました。  (Noah Misch, Arun Thirupathi) (14.18)(13.21)</li>
<p>
これは15.x以降バージョンむけの修正の後方適用です。当初は外観的な修正と考えられていましたが、その後の修正を通してデータ破損の防止に有効と判明しました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3635a0a35">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=69a498eb6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=014a50800">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a5b0c06da">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=675b771ca">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cbed472a9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b494640e8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d0b6acaf0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8967dddf0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=20e5ef3ca">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6b168c129">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=df8ec9634">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=47d2d2982">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e77d9cd4f">&#167;</a></small></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 13.20 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/13-20/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Fri, 28 Feb 2025 04:32:07 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 13]]></category>
		<category><![CDATA[PostgreSQL 13.19]]></category>
		<category><![CDATA[PostgreSQL 13.20]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=16510</guid>

					<description><![CDATA[このリリースは 13.19 からの修正リリース（2025年 2月 20日リリース）です。 13.X からのアップデートではダンプ、リストアは不要です。 ただし、13.17 よりも前のバージョンからアップデートする場合には ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 13.19 からの修正リリース（2025年 2月 20日リリース）です。<br />
13.X からのアップデートではダンプ、リストアは不要です。</p>
<p>ただし、13.17 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/13-17/" rel="noopener">13.17のリリース情報</a>も参照してください。</p>
<p><span id="more-16510"></span></p>
<h3>PostgreSQL 13.19 から 13.20 への変更点</h3>
<p>17.4, 16.8, 15.12, 14.17, 13.20 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>libpqのクォート付加を行うAPI関数について追加の修正が行われました。  (Andres Freund, Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
CVE-2025-1094への対応で、1つ重大な見落としがありました。PQescapeLiteral() およびPQescapeIdentifier() は、文字列の長さを指定するパラメータを適切に考慮せず、入力文字列のヌル終端文字までを常に読み取っていました。この結果、呼び出し側が長さを指定するパラメータを使用して文字列を切り詰めようとしていた場合でも、不要なテキストが出力に含まれる可能性がありました。さらに、入力テキスト文字列がヌル終端文字がない場合、不正なメモリを読み込み、クラッシュを引き起こす可能性がありました。
</p>
<p>
合わせて、これらのクオート関数のすべてにおいて、無効なエンコーディングが検出された際の処理が変更されました。これまでは無効なシーケンス全体を置き換えていましたが、今回の変更では、その文字の最初のバイトのみが置き換えられました。これにより、クオート済みの文字列に対して呼び出し側アプリケーションが追加の処理を行った場合のリスクを低減できます。
</p>
<li>pg_createsubscriberの小さなメモリリークが修正されました。  (Ranier Vilela) (17)</li>
<li>mesonがbsd_auth.hを利用できるか正しく検知できるよう修正されました。  (Nazir Bilal Yavuz) (17)(16)</li>
<li>遷移テーブルを利用するパーティションテーブルのトリガーに関するクラッシュが修正されました。  (Kyotaro Horiguchi) (14)(13)</li>
<p>
AFTER UPDATEトリガーとAFTER DELETEトリガーの両方が存在する場合、遷移テーブルの必要性が誤って判定されていました。この誤判定により、パーティションをまたぐ更新をした際にクラッシュする問題がありました。
</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 13.19 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/13-19/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Fri, 28 Feb 2025 04:25:26 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 13]]></category>
		<category><![CDATA[PostgreSQL 13.18]]></category>
		<category><![CDATA[PostgreSQL 13.19]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=16493</guid>

					<description><![CDATA[このリリースは 13.18 からの修正リリース（2025年 2月 13日リリース）です。 13.X からのアップデートではダンプ、リストアは不要です。 ただし、13.17 よりも前のバージョンからアップデートする場合には ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 13.18 からの修正リリース（2025年 2月 13日リリース）です。<br />
13.X からのアップデートではダンプ、リストアは不要です。</p>
<p>ただし、13.17 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/13-17/" rel="noopener">13.17のリリース情報</a>も参照してください。</p>
<p><span id="more-16493"></span></p>
<h3>PostgreSQL 13.18 から 13.19 への変更点</h3>
<p>17.3, 16.7, 15.11, 14.16, 13.19 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>PQescapeString などの関数が無効なエンコーディングの入力文字列に対して頑強になりました。(CVE-2025-1094)  (Andres Freund, Noah Misch) (17)(16)(15)(14)(13)</li>
<p>
クライアントライブラリ libpq で提供されるクォートを付加する関数群は、これからは入力のエンコーディング正当性の検査を十分に行うようになります。無効な文字が検出された場合、可能であればエラーを返します。エラーを返す規則が無い場合には、確実にサーバが無効なエンコーディングを報告し、介在するプロセスがシングルクォートやバックスラッシュ等に偶然一致するバイト列に騙されないように、出力文字列が調整されます。
</p>
<p>
本変更は、作りこまれた入力をこれらの関数でクォートすることで可能となる SQL インジェクション攻撃を防止する目的です。サーバ側で必ずエンコーディング検査が行われるので、関数でクォートした結果の文字列を直接 PostgreSQL サーバに送っているときには危険はありません（一般的にはこのように使用しているはずです）。しかしながら、結果の文字列を psql や他のクライアント側のコードに渡している場合に危険がありました。歴史的にこれらのコードはエンコーディングを注意深く検査しておらず、また、多くの場合に不正コードに対する挙動が明確にされていませんでした。
</p>
<p>
本修正が有効なのは、クォート関数とサーバ、および、介在する処理が、使用する文字エンコーディングについて合意している場合に限られます。信用できない入力を SQL コマンドに挿入するアプリケーションはこの点を確実にしなければなりません。
</p>
<pre>
本修正に該当する libpq の API関数:
PQescapeLiteral()
PQescapeIdentifier()
PQescapeString()
PQescapeStringConn()
</pre>
<li>接続要求でのデータベース名とユーザ名の自動切り捨てが元に戻されました。  (Nathan Bossart) (17)</li>
<p>
これは一部で問題を引き起こすと判明した 17.0 の変更を元に戻すものです。name 型の最大長 64バイト（実装コードでは NAMEDATALEN - 1）以上の名前を切り捨てるときに文字エンコーディングを認識するようになりましたが、従来の単にバイト数で切り捨てる動作に戻されました。
</p>
<p>
長さが超過したデータベース名やユーザ名で接続できていたものが、できなくなってしまった事象が報告されました。
</p>
<pre>
（16.x と本修正以降では以下の「FATAL:  role ... does not exist」は発生しない）
db1=# CREATE USER aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggggggg;
NOTICE:  identifier "aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggggggg" will be truncated to "aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffggg"
CREATE ROLE
db1=# \c db1 aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggggggg
connection to server on socket "/tmp/.s.PGSQL.5432" failed: FATAL:  role "aaaaaaaaaabbbbbbbbbbccccccccccddddddddddeeeeeeeeeeffffffffffgggggggg" does not exist
Previous connection kept
</pre>
<li>接続権限と接続数上限の検査からパラレルワーカーが除外されました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
pg_database の datallowconn、pg_roles の rolcanlogin、および（GRANT/REVOKE で制御する）ロールのデータベースに対する CONNECT 権限を、パラレルワーカー開始時に検査しなくなりました。リーダープロセスで同様の検査を通っているので、それだけで十分と判断されました。これにより、例えば、パラレル問い合わせでログイン権限の無いロールでリーダープロセスが動作しているときの予期せぬエラーを回避できます。
</p>
<p>
同様に、reserved_connections 設定や pg_database の datconnlimit、pg_roles の rolconnlimit による接続数上限の検査も、通常のバックエンドのみに行うようになりました。
</p>
<li>待機イベント型が「LWLock」の待機イベント名から、接尾辞「Lock」が取り除かれました。  (Bertrand Drouvot) (17)</li>
<p>
pg_wait_events ビューでは「Lock」が付加されない待機イベント名（name列）が出力されるため、pg_stat_activity ビューの wait_event 列の値と不一致が生じていました。本修正で「LWLock」型については「Lock」が付加されない待機イベント名に統一されます。
</p>
<p>
17.0～17.2 に対して非互換の変更となります。
</p>
<li>ScalarArrayOp の条件（「IN (...)」や「= ANY」）で Btree インデックスをスキャンして一致する全タプルを返すときに、誤った問い合わせ結果が生じる可能性があり、修正されました。  (Peter Geoghegan) (17)</li>
<li>ウィンドウ集約で古い結果を再利用してしまう可能性があり、修正されました。  (David Rowley) (17)(16)(15)</li>
<p>
Run Condition: 最適化を伴う WindowAgg プラン要素が使われて、結果データ型が（text などの）リファレンス渡しの型であった場合に、新たな計算結果ではなく手前のパーティションの結果が再利用されてしまい、クラッシュや誤った問い合わせ結果が生じる可能性がありました。
</p>
<li>TransactionXmin と MyProc->xmin の同期が維持されるようになりました。  (Heikki Linnakangas) (17)(16)(15)(14)(13)</li>
<p>
この誤りにより、プロセスが VACUUM 済みのデータにアクセスを試みてしまう可能性がありました。知られている症状は一時的にエラー「ERROR: could not access status of transaction」が発生することです。
</p>
<p>
TransactionXmin と MyProc->xmin はいずれも実装コード中の変数で、実行中トランザクションの最小トランザクションID を意味します。
</p>
<li>カタログキャッシュリストに新たに挿入されたカタログエントリを追加することに失敗するかもしれない競合状態が修正されました。  (Heikki Linnakangas) (17)(16)(15)(14)(13)</li>
<p>
これにより例えば、既存セッション内で新たに作られた関数を使用できない、といったことが発生します。
</p>
<li>システムカタログが UPDATE と並行して VACUUM されたときにデータ破損する可能性があり、防止されました。  (Noah Misch) (17)(16)(15)(14)(13)</li>
<li>リレーション切り詰めに失敗したときのデータ破損が修正されました。  (Thomas Munro) (17)(16)(15)(14)(13)</li>
<p>
リレーション切り詰めを実行するためのファイルシステムコールは失敗する可能性があり、例えば削除されたデータが生き返ってしまうなど、ストレージに一貫性に欠けた状態を残します。これを本当に防ぐことはできませんが、そのような失敗を PANIC にすることで回復することができます。すなわち、リカバリ起動の WAL リプレイで切り詰めを試みた直前まで復旧することで一貫性が回復します。これはとても望ましい振る舞いではありませんが、ファイル切り詰め失敗は十分に稀な事象であり、受け入れ可能な解決策と判断されました。
</p>
<p>
PANIC を起こさない従来の振る舞いはスタンバイでのエラーやデータ不一致の原因となっていて、これまでは VACUUM 処理でファイル切り詰めを無効化することが対策でした。
</p>
<li>リレーション切り詰め中のチェックポイント開始を防止するようになりました。  (Robert Haas) (17)(16)(15)(14)(13)</li>
<p>
これにより修正されたファイルがチェックポイント完了前に fsync されず、そこで OS がクラッシュしたときにデータ破損の危険が生じるという、競合状態を回避します。
</p>
<li>データベース所有者を変更する REASSIGN OWNED と VACUUM が同時実行するときに pg_database.datfrozenxid の更新が失われる可能性があり、修正されました。  (Kirill Reshke) (17)(16)(15)(14)(13)</li>
<li>AFTER UPDATE のトリガに誤った tg_updatedcols 値が渡されており、修正されました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
一部の場合に tg_updatedcols ビットマップに同トランザクション内の手前のコマンドで更新された列がセットされる可能性があり、これはトリガの誤動作の原因となります。
</p>
<p>
tg_updatedcols は C 言語で記述する更新トリガで受け取ることができる変数で、どの列が更新されたかを示すビットマップ値が格納されます。
</p>
<li>パーティションテーブルを参照する外部キー制約を持つパーティションのデタッチが修正されました。  (Amul Sul) (17)(16)(15)</li>
<p>
外部キー制約が（パーティションテーブル全体ではなく）特定のパーティションに定義されていて、それが何らか別のパーティションテーブルを参照している場合、その外部キー制約を持つパーティションをデタッチすると、対応する pg_constraint のエントリが誤って更新されました。
</p>
<p>
これにより、「ERROR:  could not find ON INSERT check triggers of foreign key constraint」のようなエラーが発生しました。
</p>
<pre>
（障害動作例）
db1=# CREATE TABLE pt1 (id int PRIMARY KEY, d text) PARTITION BY RANGE(id);
db1=# CREATE TABLE pt1p1 PARTITION OF pt1 FOR VALUES FROM (0) TO (100);
db1=# CREATE TABLE pt2 (a int, b int) PARTITION BY LIST (a);
db1=# CREATE TABLE pt2p1 PARTITION OF pt2 FOR VALUES IN (1);
db1=# ALTER TABLE pt2p1 ADD FOREIGN KEY (a) REFERENCES pt1 (id);
db1=# ALTER TABLE pt2 DETACH PARTITION pt2p1;
ERROR:  could not find ON INSERT check triggers of foreign key constraint 103641
</pre>
<li>pg_get_constraintdef のドメインに対する NOT NULL制約の対応が修正されました。  (Alvaro Herrera) (17)</li>
<p>
pg_get_constraintdef 関数がドメインの NOT NULL制約に対応した、システムカタログ pg_constraint の行の OID に対して、「NOT NULL」という文字列を返すべきところ、エラー「ERROR:  invalid constraint type "n"」を出していました。
</p>
<li>to_timestamp 関数の「FFn」書式コードの誤った処理が修正されました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
数値をつなげた書式の場合に、FF1 から FF6 の指定がいずれも正しく動作しませんでした。
</p>
<pre>
（誤動作例）
db1=# SELECT to_timestamp('20251122123456123456', 'YYYYMMDDHH24MISSFF1');
ERROR:  date/time field value out of range: "20251122123456123456"

（期待される応答）
       to_timestamp
--------------------------
 2025-11-22 12:34:56.1+09
(1 row)

（問題が生じない区切り文字があるケース）
db1=# SELECT to_timestamp('2025-11-22 12:34:56.123456', 'YYYY-MM-DD HH24:MI:SS.FF3');
        to_timestamp
----------------------------
 2025-11-22 12:34:56.123+09
(1 row)
</pre>
<li>SQL/JSON問い合わせ関数で PASSING 句を逆パースするときに、必要なとき確実に変数名がダブルクォートされるようになりました。  (Dean Rasheed) (17)</li>
<p>
JSON_EXISTS()、JSON_QUERY()、JSON_VALUE() が該当します。逆パースはビューをダンプ出力したり定義表示したりするときに行われます。
</p>
<pre>
（誤動作例: 「AS "Xyz"」が「AS Xyz」になってしまっている）
db1=# CREATE VIEW v17 AS
        SELECT JSON_QUERY(jsonb 'null', '$"Xyz"' PASSING 1 AS "Xyz");
db1=# \sv v17
CREATE OR REPLACE VIEW public.v17 AS
 SELECT JSON_QUERY('null'::jsonb, '$"Xyz"' PASSING 1 AS Xyz RETURNING jsonb WITHOUT WRAPPER KEEP QUOTES) AS "json_query";
</pre>
<li>XMLTABLE() 関数の式の逆パースで、XML ネームスペース名が必要なとき確実にダブルクォートされるようになりました。  (Dean Rasheed) (17)(16)(15)(14)(13)</li>
<p>
逆パースはビューをダンプ出力したり定義表示したりするときに行われます。
</p>
<pre>
（誤動作例:「AS "Zz"」が「AS Zz」になってしまっている）
db1=# CREATE VIEW v18 AS SELECT * FROM
        XMLTABLE(XMLNAMESPACES('http://x.y/' AS "Zz"), '/Zz:rows/Zz:row'
		PASSING '<rows xmlns="http://x.y/"><row><a>10</a></row></rows>'
        COLUMNS a int PATH 'Zz:a');
db1=# \sv v18
CREATE OR REPLACE VIEW public.v18 AS
 SELECT a
   FROM XMLTABLE(XMLNAMESPACES ('http://x.y/'::text AS Zz), ('/Zz:rows/Zz:row'::text) PASSING ('<rows xmlns="http://x.y/"><row><a>10</a></row></rows>'::xml) COLUMNS a integer PATH ('Zz:a'::text))
</pre>
<li>pg_hba_file_rules() 関数の出力に、これまで欠落していた ldapscheme オプションを含めるようになりました。  (Laurenz Albe) (17)(16)(15)(14)(13)</li>
<li>入力列のデータ型が全ては一致しない場合における、ソート済 UNION 操作のプラン作成が修正されました。  (David Rowley) (17)</li>
<p>
この障害は、誤ったソート演算子によるデータのソートを引き起こし、その結果はクラッシュから目に見える問題が無い場合まで様々です。
</p>
<pre>
（報告されたクラッシュする例）
db1=# CREATE TABLE t20 (c1 int, c2 numeric);
db1=# INSERT INTO t20 VALUES (0, NULL), (8, NULL);
db1=# SELECT c2, c2 FROM t20
      UNION
      SELECT DISTINCT c2, ta1.c1 FROM (
        SELECT c1, c2 FROM t20) AS ta1
        JOIN (SELECT c1, c1 FROM t20) AS ta2 ON true;
server closed the connection unexpectedly
</pre>
<li>列の照合順序が一貫していない場合は、UNION 操作を併合しないように修正されました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
以前は、いくつかの UNION 操作を 1つに統合しても安全か判断する際に、照合順序が無視されていました。これは非決定論的照合順序が導入される前はおそらく有効でしたが、現在は有効ではありません。照合順序が一意性の定義に影響を与える可能性がありました。
</p>
<pre>
db1=# CREATE TABLE t21a (c text);
db1=# CREATE TABLE t21b (c text);
db1=# CREATE TABLE t21c (c text COLLATE "ja_JP");
db1=# explain SELECT c FROM t21a UNION SELECT c FROM t21b UNION SELECT c FROM t21c;
（17.2の実行プラン - 1つの Append と HashAggregate にまとめられている）
                                    QUERY PLAN
----------------------------------------------------------------------------------
 HashAggregate  (cost=128.60..169.40 rows=4080 width=32)
   Group Key: (("*SELECT* 1".c)::text)
   ->  Append  (cost=0.00..118.40 rows=4080 width=32)
         ->  Subquery Scan on "*SELECT* 1"  (cost=0.00..37.20 rows=1360 width=32)
               ->  Seq Scan on t21a  (cost=0.00..23.60 rows=1360 width=32)
         ->  Subquery Scan on "*SELECT* 2"  (cost=0.00..37.20 rows=1360 width=32)
               ->  Seq Scan on t21b  (cost=0.00..23.60 rows=1360 width=32)
         ->  Seq Scan on t21c  (cost=0.00..23.60 rows=1360 width=32)
(8 rows)
（17.3の実行プラン - 2段階に分かれている）
                                   QUERY PLAN
---------------------------------------------------------------------------------
 HashAggregate  (cost=149.00..189.80 rows=4080 width=32)
   Group Key: ((t21a.c)::text)
   ->  Append  (cost=67.60..138.80 rows=4080 width=32)
         ->  HashAggregate  (cost=67.60..94.80 rows=2720 width=32)
               Group Key: t21a.c
               ->  Append  (cost=0.00..60.80 rows=2720 width=32)
                     ->  Seq Scan on t21a  (cost=0.00..23.60 rows=1360 width=32)
                     ->  Seq Scan on t21b  (cost=0.00..23.60 rows=1360 width=32)
         ->  Seq Scan on t21c  (cost=0.00..23.60 rows=1360 width=32)
(9 rows)
</pre>
<li>外部結合の下にあるサブクエリをプルアップした後に生じるプランナのエラー「ERROR:  wrong varnullingrels ...」を防止するようになりました。  (Tom Lane) (17)(16)</li>
<li>プランナが統計情報を調べるときに、NULL になるリレーションのマーカービット（nullingrels）を無視するように修正されました。  (Richard Guo) (17)(16)</li>
<p>
本障害により、外部結合を含む問い合わせで、式に関する統計が使用できなかったり、「ERROR:  corrupt MVNDistinct entry」が発生する可能性がありました。
</p>
<li>パーティションプルーニングで式を書き換えする処理が欠落しており、修正されました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
この見落としにより、パーティションテーブルにアクセスする問い合わせで「ERROR:  unrecognized node type ..」やその他の問題が発生する可能性がありました。
</p>
<li>slotsync ワーカープロセスに独自のプロセススロットを割り当てるようになりました。  (Tom Lane, Hou Zhijie) (17)</li>
<p>
これは slotsync ワーカーの追加時に見落とされ、その結果、そのプロセススロットが通常のバックエンドプロセス用のプールから実質的に取得されていました。これにより、通常のバックエンドプロセス数が max_connections に近づいた場合、ワーカーの起動に失敗したり、構成された設定に従って成功するはずだった接続要求が失敗したりする可能性がありました。
</p>
<p>
slotsync ワーカーはストリーミングレプリケーションのフェイルオーバに対応したロジカルレプリケーションを構成するときに使われます。
</p>
<li>dshash テーブルの 1GB を超える割り当てが許可されるようになりました。  (Matthias van de Meent) (17)(16)(15)(14)(13)</li>
<p>
これにより「ERROR:  invalid DSA memory alloc request size ..」などのエラーを回避できるようになりました。これは、例えば数百万のテーブルを処理するトランザクションで発生する可能性があります。
</p>
<p>
dshash テーブルは実装内部の要素で、動的共有メモリ（DSM）を利用してプロセス間でデータ共有するためのハッシュデータ構造です。
</p>
<li>bringetbitmap() で整数オーバーフローが発生する可能性があり、回避するようになりました。  (James Hunter, Evgeniy Gorbanyov) (17)(16)(15)(14)(13)</li>
<p>
bringetbitmap() は brin インデックスの実装コード内の関数です。結果値は統計目的のみで使用されるため、この誤りの動作への影響はほとんどありません。
</p>
<li>SLRU のバンク数の計算誤りが修正されました。  (Yura Sokolov) (17)</li>
<p>
このエラーにより、意図したよりも少ない数のバンクが使用され、競合が増加しましたが、機能上の不具合はありませんでした。
</p>
<li>すでに設定されているプロセスのラッチによって、親プロセス(postmaster)によるソケットイベントの認識が妨げられないように、修正されました。  (Thomas Munro) (17)(16)</li>
<p>
ワーカーを起動したり終了したりするバックエンドの負荷が非常に大きいことで、親プロセスがクライアントからの接続要求に即応できなくなるおそれがありました。
</p>
<p>
ラッチは PostgreSQL 実装内の排他制御の仕組みの 1つです。
</p>
<li>ページをまたぐ WAL レコードの読み取り時に、ストリーミングスタンバイサーバが無限ループするのを防ぐようになりました。  (Kyotaro Horiguchi, Alexander Kukushkin) (17)(16)(15)(14)(13)</li>
<p>
これは、レコードの続きが別の WAL ソースから読み取る必要があるページにある場合に発生します。
</p>
<li>プロセスの起動初期に意図せず FATAL エラーが PANIC に昇格する問題が修正されました。  (Noah Misch) (17)(16)(15)(14)(13)</li>
<p>
これにより、稀に発生していた「PANIC:  proc_exit() called in child process」が生じるケースを回避できます。
</p>
<li>演算子族メンバーの演算子、またはサポートプロシージャが不正参照となる可能性があり、修正されました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
場合によっては、データ型が削除されても、その OID への参照が pg_amop または pg_amproc に残っている可能性がありました。これによってすぐに問題が発生することはありませんが、それを所有する演算子族を削除しようとすると失敗し、演算子族をダンプするときに pg_dump が誤った出力を生成することになります。
</p>
<p>
この修正により、演算子族/クラスの作成と変更によって必要な依存関係エントリが追加され、データ型を削除すると、依存する演算子族要素も削除されます。ただし、これは脆弱な既存の演算子族には役立ちません。そのため、不正なメンバーを持つ演算子族を削除するときに失敗しないように、DROP OPERATOR FAMILY コマンドにも手当てが行われました。
</p>
<li>ロジカルデコーディング出力における複数のメモリリークが修正されました。  (Vignesh C, Masahiko Sawada, Boyu Yang) (17)(16)(15)(14)(13)</li>
<li>application_name または cluster_name 設定を更新するときに発生する小さなメモリリークが修正されました。  (Tofig Aliev) (17)(16)</li>
<li>バックグラウンドプロセスが synchronized_standby_slots の新しい値を検査しようとした時に発生するクラッシュが回避されました。  (Alvaro Herrera) (17)</li>
<li>wal_skip_threshold 条件を検査するときの整数オーバーフローが回避されるようになりました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
非常に大きなリレーションを作成したトランザクションが、誤ってリレーションを fsync する代わりに WAL にコピーすることで耐久性を確保すると決定し、wal_skip_threshold の目的を否定する可能性がありました。これは、wal_level が minimal に設定されている場合にのみ関係し、それ以外の場合は、いずれにしても WALコピーが必要です。
</p>
<li>キャッシュ検索中の安全でない操作順序が修正されました。  (Noah Misch) (17)(16)(15)(14)(13)</li>
<p>
判明している症状は GRANT TABLESPACE の際に、「WARNING:  you don't own a lock of type ExclusiveLock」が出力されることだけで、これは通常無害です。
</p>
<li>並列バキュームで解放後メモリアクセスの可能性が回避されました。  (Vallimaharajan G, John Naylor) (17)</li>
<p>
本障害は標準的なビルドでは影響がないと考えられますが、理論的には危険です。
</p>
<li>古い ARM プラットフォームで JIT を使用するときに「ERROR:  failed to resolve name」エラーが発生する可能があり、修正されました。  (Thomas Munro) (17)(16)(15)(14)(13)</li>
<p>
これは、gcc と clang 間の -moutline-atomics のデフォルト設定に関する不一致の結果として発生する可能性がありました。少なくとも Debian と Ubuntu は、armv8-a をターゲットとする gcc コンパイラと clang コンパイラを同梱していることが知られていますが、アウトラインアトミックを使用するかのデフォルトが異なります。
</p>
<li>「WITH RECURSIVE ... UNION」の問い合わせでのアサート失敗が修正されました。  (David Rowley) (17)(16)(15)(14)(13)</li>
<li>集合操作のリーフクエリに集合操作が含まれている場合に、ルールの逆解析でアサート失敗が発生しなくなりました。  (Man Zeng, Tom Lane) (17)(16)(15)(14)(13)</li>
<li>並列クエリ起動時に発生するエッジケースのアサート失敗が回避されました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<li>シャットダウン時に統計ファイルを書き出す際のアサート失敗が修正されました。  (Michael Paquier) (17)(16)(15)</li>
<li>文字列ハッシュコードに関する Valgrind エラーが回避されました。  (John Naylor) (17)</li>
<li>NULLIF() では、読み書き拡張オブジェクトポインタをデータ型の等価関数に渡さないようになりました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
読み書きポインタが渡されると、等価関数はオブジェクトを変更したり削除したりする可能性があります。これは、NULLIF() の結果としてそれを返すことにした場合、好ましくありません。組み込みの等価関数ではおそらく問題はありませんが、PL/pgSQL でコーディングされた等価関数では簡単に失敗を実証できます。
</p>
<li>INSERT のデフォルトの NULL 値に式の前処理が確実に適用されるようになりました。  (Tom Lane) (17)(16)(15)(14)</li>
<p>
対象列がドメイン型の場合、プランナは単なる NULL 定数だけでなく coerce-to-domain ステップを挿入する必要があり、この式は必要なステップをいくつか実行できませんでした。コアデータ型に基づくドメインでは既知の影響はありませんが、理論的には、拡張型に基づくドメインでエラーが発生する可能性がありました。
</p>
<li>すでにデータが含まれているリレーションフォークで一括書き込みを開始したときのデータ損失が回避されました。  (Matthias van de Meent) (17)</li>
<p>
既存のデータはすべてゼロで上書きされます。コア PostgreSQL ではこのようなことは決しておこなわれませんので、これは PostgreSQL のコアでは問題ではありません。しかし、一部の拡張ではこのようなことがおこなわれます。
</p>
<li>サーバプロセスが作成していない共有基数木を反復処理しようとした場合のクラッシュが回避されました。  (Masahiko Sawada) (17)</li>
<p>
PostgreSQL のコアにはこれを実行するコードはありませんが、拡張では実行を希望するかもしれません。
</p>
<li>PL/Python のメモリリークが修復されました。  (Mat Arye, Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
PLyPlan.execute または plpy.cursor を繰り返し使用すると、PL/Python 関数の呼び出し中にメモリリークが発生していました。
</p>
<li>PL/Tcl が Tcl 9 でコンパイルできるように修正されました。  (Peter Eisentraut) (17)(16)(15)(14)(13)</li>
<li>ecpg プリプロセッサで、スコープ外の変数を参照するカーソルを誤って処理する可能性が修正されました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<li>ecpg で、サポートされていない COPY ... FROM STDIN の使用に関するコンパイル時の警告が修正されました。  (Ryo Kanbayashi) (17)(16)(15)(14)(13)</li>
<p>
以前は、タイプミスが原因で意図した警告が発行されていませんでした。
</p>
<li>SJIS でエンコードされたファイルパス名を安全に扱えるように psql が修正されました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
SJIS の一部の 2 バイト文字には、2 バイト目が ASCII バックスラッシュ ("\") に等しいものがあります。これらの文字はパス名の正規化によって破壊され、そのような文字を含む名前を持つファイルへのアクセスが妨げられていました。
</p>
<li>COPY (MERGE INTO) のための psql タブ補完機能が追加されました。  (Jian He) (17)</li>
<li>pgbench および psql での pqsignal() の間違ったバージョンの使用が修正されました。  (Fujii Masao, Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
このエラーにより、中断されたシステムコールが期待どおりに再開されないため、pgbench の -T オプションを使用する際、もしくは psql の \watch コマンドを使用する際に、誤動作につながる可能性がありました。
</p>
<li>pgbench 内の一部のネストされた \if 構造の誤った実行が修正されました。  (Michail Nikolaev) (17)(16)(15)(14)(13)</li>
<p>
結果が false となる \if 分岐中に現れる \if コマンドが誤って \elif と同じように処理されていました。
</p>
<li>pgbench でテーブルの初期化中に進行状況メッセージが誤って表示される可能性がある問題が修正されました。  (Yushi Ogiwara, Tatsuo Ishii, Fujii Masao) (17)(16)(15)(14)(13)</li>
<li>pg_controlldata が破損した pg_control ファイルに対してより堅牢になりました。  (Ilyasov Ian, Anton Voloshin) (17)(16)(15)(14)(13)</li>
<p>
pg_controlldata は CRC チェックが失敗した場合でも pg_control の内容を出力しようとするため、無効なフィールド値に対して誤動作しないように注意する必要があります。このパッチにより、無効なタイムスタンプと明らかに負の WAL セグメントサイズによって引き起こされるいくつかの問題が修正されました。
</p>
<li>拡張のメンバであるテーブルに ID シーケンスで添付されている場合にpg_dump で発生する可能性があるクラッシュが修正されました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<li>zstd で圧縮されたデータを使用した際の pg_restore メモリリークが修正されました。  (Tom Lane) (17)(16)</li>
<p>
メモリリークは解凍操作ごとに発生するため、多数のテーブルや大きなオブジェクトを含むダンプで最も顕著になります。
</p>
<li>Windows で pg_basebackup が 2GB を超える pg_wal.tar ファイルを扱えるようになりました。  (Davinder Singh, Thomas Munro) (17)(16)(15)(14)(13)</li>
<li>contrib/earthdistance の SQL 関数宣言がSQL標準形式に変更されました。  (Tom Lane, Ronan Dunklau) (17)(16)</li>
<p>
これにより、拡張機能インストール時に contrib/cube への依存関係を解決できるようになり、検索パスに基づく障害や攻撃のリスクが軽減されます。
</p>
<p>
とくに v17 では、セキュリティ上の理由で検索パスが制限されたため、生成列などで使用できず、サーバをバージョンアップできないと報告を受けていました。そのため、この修正は v16 にも含まれており、拡張機能を事前にバージョンアップすれば、サーバをバージョンアップできるようになります。
</p>
<li>contrib/pageinspect で SQL 宣言と共有ライブラリ間のバージョン不一致を検出するようになりました。  (Tomas Vondra) (17)</li>
<p>
以前は、brin_page_items()呼び出し時にクラッシュが発生する可能性がありましたが、代わりに拡張機能の更新を推奨するエラーが出力されます。
</p>
<li>contrib/postgres_fdw でリモートクエリキャンセル時に反応がない場合に数回再リクエストするになりました。  (Tom Lane) (17)</li>
<p>
これにより、リモートサーバでクエリ処理開始前にキャンセルしようとして発生する競合状態が解消され、最初のリクエストが無視されるようになります。
</p>
<li>ARM で CRC 命令を使用するようにコンパイラ設定が更新されました。  (Tom Lane) (17)(16)(15)(14)(13)</li>
<p>
CRC 命令をデフォルトで非対応の ARM 環境で使用するには -march オプションが必要ですが、最近の gcc では誤った設定でもエラーにならず、代わりに低速なソフトウェア CRC が選択されていました。
</p>
<li>Windows で meson ビルド時に古い OpenSSL ライブラリをサポートするようになりました。  (Darek Slusarczyk) (17)(16)</li>
<p>
古いライブラリ名 ssleay32 および libeay32 がサポートされます。
</p>
<li>Windows で meson ビルド時に全 libcommon および libpgport 関数のエクスポートを確認するようになりました。  (Vladlen Popolitov, Heikki Linnakangas) (17)(16)</li>
<p>
これにより、拡張機能ビルド時の unresolved external symbol エラーが解消されます。
</p>
<li>meson ビルド時に MSVC で OSSP の uuid.h ヘッダファイルが検出できるようになりました。  (Andrew Dunstan) (17)(16)</li>
<li>meson ビルド時の pgevent インストール先が bindir から pkglibdir に変更されました。  (Peter Eisentraut) (17)(16)</li>
<p>
これは、 make および古い MSVC ビルド時と動作を一致させるための変更です。
</p>
<li>meson ビルド時の sepgsql.sql インストール先が share/extension/ から share/contrib/ に変更されました。  (Peter Eisentraut) (17)(16)</li>
<p>
これは、make ビルド時と動作を一致させるための変更です。
</p>
<li>パラグアイの DST 法変更とフィリピンの歴史的修正のため、  (Tom Lane) (17)(16)(15)(14)(13)</li>
<p>タイムゾーンデータファイルが tzdata release 2025a に更新されました。
</p>
<li>ファイル名変更時に link()/unlink() ではなく、 rename() を使用するようになりました。  (Nathan Bossart) (15)(14)(13)</li>
<p>
以前は、既存ファイルが誤って上書きされるのを防ぐため、そうなっていましたが、途中で処理に失敗すると、同じファイルへのリンクが2つ存在した状態となり、後続の処理が混乱し、データ破損のリスクがありました。実際には、変更先のファイルが存在する状況でこの処理は行われないため、上書き防止よりデータ破損のリスクを回避したほうがよいと判断されました。
</p>
<li>malloc() 失敗時の戻り値チェック漏れのため、メモリ不足時にまれに発生するクラッシュが修正されました。  (Karina Litskevich) (15)(14)(13)</li>
<li>Windows でジャンクションポイントの扱いを修正しました。  (Thomas Munro) (15)(14)(13)</li>
<p>
以前は、データディレクトリに相対パスでジャクションポイントを指定した場合や、ジャクションポイントが別のジャンクションポイントを指している場合、initdb が失敗していました。
</p>
<li>configure 中に C23 規格のコンパイラが検出されても、 C17 を使用するようになりました。  (Thomas Munro) (15)(14)(13)</li>
<p>
v16 より前は C23 規格ではコンパイルできないため、検出されたコンパイラが C23 以降の場合、-std=gnu17 オプションで変更するようになりました。それでもコンパイルできない場合、 CFLAGS に手動でオプションを指定してください。
</p>
<li>archive_status ディレクトリ内に状態ファイルが大量に存在する状況で、archiver プロセスのパフォーマンスが改善されました。  (Nathan Bossart) (14)</li>
<p>
この変更は、アーカイブのパフォーマンスが極端に低下し、ダウンタイムやレプリカ損失につながるという報告を受け、もとは v15 で行われた修正がバックパッチされたものとなります。
</p>
<li>リレーション切り捨て中にまれに発生するアサート失敗が修正されました。  (Heikki Linnakangas) (13)</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 13.18 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/13-18/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Wed, 18 Dec 2024 05:17:17 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 13]]></category>
		<category><![CDATA[PostgreSQL 13.17]]></category>
		<category><![CDATA[PostgreSQL 13.18]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=15896</guid>

					<description><![CDATA[このリリースは 13.17 からの修正リリース（2024年 11月 21日リリース）です。 13.X からのアップデートではダンプ、リストアは不要です。 ただし、13.17 よりも前のバージョンからアップデートする場合に ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 13.17 からの修正リリース（2024年 11月 21日リリース）です。<br />
13.X からのアップデートではダンプ、リストアは不要です。</p>
<p>ただし、13.17 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/13-17/" rel="noopener">13.17のリリース情報</a>も参照してください。</p>
<p><span id="more-15896"></span></p>
<h3>PostgreSQL 13.17 から 13.18 への変更点</h3>
<p>17.2、16.6、15.10、14.15、13.18、12.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>ResultRelInfo 構造体と連携するエクステンションに対する ABI 破壊が修正されました。  (Tom Lane) (17)(16)(15)(14)</li>
<p>
2024/11/14のマイナーリリースにより、timescaledb や他のいくつかの拡張機能とのバイナリ互換性が意図せず壊れていました。ResultRelInfo 構造体を以前のサイズに戻されたことで、影響を受けたエクステンションをビルドし直す必要がなくなりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6bfacd368">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ee33d5847">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=17db248f3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=099e711b7">&#167;</a></small></p>
<li>ALTER {ROLE|DATABASE} SET ROLE などが機能しなくなっていた問題が修正されました。  (Tom Lane, Noah Misch) (17)(16)(15)(14)(13)(12)</li>
<p>
CVE-2024-10978 の修正により、非対話的なソース（ ALTER {ROLE|DATABASE}  コマンドや PGOPTIONS 環境変数など）から設定されたロールの設定が適用されなくなる問題が発生していましたが、修正されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1c05004a8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b0918c128">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=edf80895f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=be062bfa5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=07c6e0f61">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c46333865">&#167;</a></small></p>
<li>論理レプリケーションスロットの restart_lsn が逆戻りすることがあった問題が修正されました。  (Masahiko Sawada) (17)(16)(15)(14)(13)</li>
<p>
以前は、論理レプリケーションを再起動すると、スロットの再起動ポイントが、pg_replication_slots で以前に通知されていた値よりも古い値として再計算されることがありました。 これは、たとえば WALファイルが後の restart_lsn 値に基づいて削除される可能性があるため、好ましくありません。その場合、レプリケーションの再起動に失敗します。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=568e78a65">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f35391133">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=91771b3fb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=26c4e8968">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=15dc1abb1">&#167;</a></small></p>
<li>pg_rewind 実行中に必要な WAL ファイルが削除される問題が修正されました。  (Polina Bungina, Alexander Kukushkin) (17)(16)(15)(14)</li>
<p>
以前は、不運なケースで、pg_rewind がプライマリからリカバリに必要なWAL ファイルを削除してしまうことがありました。
</p>
<p>
特に、WALファイルがアーカイブ可能であるものの、まだアーカイブされていない場合（つまり、.ready ファイルが作成されているとき）に問題がありました。 以前のpg_rewind この状況ではこれらの WAL ファイルを削除してしまいました。さらに、新しく昇格したノードから取得でもこれらのWAL ファイルがリサイクル・削除してしまうと、 pg_rewind を実行したノードはリカバリに必要な WAL ファイルを入手することができずリカバリが失敗していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cb844d66b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ea1649c35">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e28cf2fbc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ba2535841">&#167;</a></small></p>
<li>共有統計エントリの削除に関連する競合状態が修正されました。  (Kyotaro Horiguchi, Michael Paquier) (17)(16)(15)</li>
<p>
これらのバグにより 統計データの損失、アサート失敗、または「ERROR:  can only drop stats once」というエラーが発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1d6a03ea4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=afa20845d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=154c5b42a">&#167;</a></small></p>
<li>pg_stat_user_indexes.idx_scan カウンターのような統計ビューで、contrib/bloom インデックス内のインデックススキャンをカウントするようになりました。  (Masahiro Ikeda) (17)(16)(15)(14)(13)</li>
<p>
以前までは実装の見落としによりカウントがされていませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7af6d1306">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=05aac2e83">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=16a2bb079">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2a30b6836">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e493ea866">&#167;</a></small></p>
<li>インデックスの opclass オプションが変更されたかどうかを確認するときに発生するクラッシュが修正されました。  (Alexander Korotkov) (17)(16)(15)(14)(13)</li>
<p>
テーブルにデフォルト以外の演算子クラスオプションを持つインデックスがある場合、ALTER TABLE の一部の処理が失敗していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a6fa869cf">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b242aba02">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=713b8546a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=247e7647f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5411e8213">&#167;</a></small></p>
<li>正規表現解析処理で発生していたアサーションエラーが回避されるようになりました。  (Tom Lane) (17)(16)(15)(14)</li>
<p>
このバグは、 configure 実行時に --enable-cassert オプションを利用してアサーション検査を有効にしたビルドでのみ影響があります。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5f28e6ba7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b6312becc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2496c3f6f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2bdd3b248">&#167;</a></small></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 13.17 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/13-17/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Wed, 18 Dec 2024 05:11:39 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 13]]></category>
		<category><![CDATA[PostgreSQL 13.16]]></category>
		<category><![CDATA[PostgreSQL 13.17]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=15882</guid>

					<description><![CDATA[このリリースは 13.16 からの修正リリース（2024年 11月 14日リリース）です。 13.X からのアップデートではダンプ、リストアは不要です。 ただし、インデックス破損を引き起こす障害の修正が含まれるため、イン ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 13.16 からの修正リリース（2024年 11月 14日リリース）です。<br />
13.X からのアップデートではダンプ、リストアは不要です。</p>
<p>ただし、インデックス破損を引き起こす障害の修正が含まれるため、インデックス再作成を行うことが望ましいです。<br />
また、13.14 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/13-14/" rel="noopener">13.14のリリース情報</a>も参照してください。</p>
<p><span id="more-15882"></span></p>
<h3>PostgreSQL 13.16 から 13.17 への変更点</h3>
<p>17.1、16.5、15.9、14.14、13.17、12.21 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>サブクエリなどトップレベル以外でのテーブル参照時に行単位セキュリティのポリシーが設定されている場合、クエリを実行したユーザの権限を無視して実行計画が不適切に使い回される可能性があり、修正されました。(Nathan Bossart) (17)(16)(15)(14)(13)(12)</li>
<p>
トップレベル以外のテーブルの参照（例えば、 CTE 、サブクエリ、 security_invoker属性が true の ビュー、SQL で作成した関数によるテーブルの参照などがこれに該当します）において、 セキュリティポリシーの設定されたテーブルを参照する場合、その実行計画がクエリを実行したロールに依存することを記録していませんでした。これにより、あるユーザの権限の元で作成したプランを、同一セッションで別の権限のユーザが実行すると、本来出力すべき行が出力されない、あるいは逆に出力すべきでない行が出力されてしまう可能性がありました。(CVE-2024-10976)
</p>
<li>SSL、GSS のネゴシエーション中に libpq が受け取ったエラーメッセージを破棄するように修正されました。(Jacob Champion) (17)(16)(15)(14)(13)(12)</li>
<p>
暗号化のネゴシエーションが完了する前に libpq が受け取ったエラーメッセージはそのまま出力していたため、中間者攻撃によって利用される恐れがありました。これにより、エラーメッセージをあたかもクエリの結果であるかのように見せかけるなどの攻撃が可能になっていました。(CVE-2024-10977)
</p>
<li>SET SESSION AUTHORIZATION と SET ROLE の間の意図しない相互作用が修正されました。(Tom Lane) (17)(16)(15)(14)(13)(12)</li>
<p>
SQL標準では、SET SESSION AUTHORIZATION が副作用として SET ROLE NONE を実行することを要求していますが、この実装に問題があり、意図しない相互作用が発生していました。特に SET SESSION AUTHORIZATION を実行したトランザクションをロールバックすると、元々のロールが NONE でない場合でも NONE に変更されてしまい、ユーザーID がトランザクション開始前と変わってしまう可能性がありました。また、関数内の SET句で一時的に session_authorization を設定すると、同様の影響がありました。関連するバグとして、パラレルワーカーに対して current_setting('role') を実行すると、正しいロールではなく none を返してしまう問題がありました。(CVE-2024-10978)
</p>
<li>「信頼されたPL/Perl (plperl)」のコードが環境変数を変更できないよう修正されました。(Tom Lane) (17)(16)(15)(14)(13)(12)</li>
<p>
PATH のようなプロセスの環境変数を操作可能であることは、攻撃者に任意のコードを実行される機会を与えることになります。このため、「信頼されたPL/Perl」はそのような能力を与えてはいけませんでした。環境変数の変更を warningメッセージとともに拒否する tied hash で %ENV を置き換える修正がされました。「信頼されないPL/perl (plperlu)」は、今までどおり環境変数を変更することも可能です。(CVE-2024-10979)
</p>
<li>ATTACH/DETACH PARTIION を実行する際に、外部キー制約に関するカタログの更新が正しく行われるよう修正されました。 (Jehan-Guillaume de Rorthais, Tender Wang, Alvaro Herrera) (17)(16)(15)(14)(13)</li>
<p>
参照先テーブルがパーティションテーブルの場合、参照元テーブルがスタンドアローンのテーブルかパーティションテーブルかで、参照元テーブルに必要なカタログエントリが異なります。ATTACH/DETACH PARTITION コマンドは、このための変換を正しく行えていませんでした。特に、DETATCH PARTITION されてスタンドアローンのテーブルとなったテーブルには、外部キー制約トリガーが作成されていませんでした。このため、外部キー制約に違反する行が挿入されてしまう可能性がありました。また、DETACH PARTITION 後に再び ATTACH PARTITION を行った場合にも予期しないエラーで失敗することがありました。
</p>
<p>
この問題が発生してしまった場合、修正するには通常のテーブルに変更されたテーブルの不正な制約に対して ALTER TABLE DROP CONSTRAINT を実行し制約を削除した後、再度制約を追加します。もし制約の再追加が失敗した場合は、誤ったデータが挿入されている可能性があります。その場合は参照元テーブルと参照先テーブル間で一貫性を手動で再度確立し、その後制約を再度追加する必要があります。
</p>
<p>
不正な制約と、正しい制約を追加するためのコマンドは、以下のクエリを実行して生成できます。
</p>
<pre>SELECT conrelid::pg_catalog.regclass AS "constrained table",
       conname AS constraint,
       confrelid::pg_catalog.regclass AS "references",
       pg_catalog.format('ALTER TABLE %s DROP CONSTRAINT %I;',
                         conrelid::pg_catalog.regclass, conname) AS "drop",
       pg_catalog.format('ALTER TABLE %s ADD CONSTRAINT %I %s;',
                         conrelid::pg_catalog.regclass, conname,
                         pg_catalog.pg_get_constraintdef(oid)) AS "add"
FROM pg_catalog.pg_constraint c
WHERE contype = 'f' AND conparentid = 0 AND
   (SELECT count(*) FROM pg_catalog.pg_constraint c2
    WHERE c2.conparentid = c.oid) &lt;&gt;
   (SELECT count(*) FROM pg_catalog.pg_inherits i
    WHERE (i.inhparent = c.conrelid OR i.inhparent = c.confrelid) AND
      EXISTS (SELECT 1 FROM pg_catalog.pg_partitioned_table
              WHERE partrelid = i.inhparent));
</pre>
<p>
ADD CONSTRAINT ステップは失敗する可能性があるため、上記のクエリの出力結果をファイルに保存し、各ステップごとに実行してください。
</p>
<li>LC_COLLATE が LC_CTYPE と異なる場合の C ロケールの判定が修正されました。 (Jeff Davis) (17)</li>
<p>
デフォルトの照合順序プロバイダとして libc を使用している場合、照合順序に C ロケールが使用されているかどうかを確認するテストでLC_COLLATE ではなく LC_CTYPE が誤ってチェックされていました。
</p>
<p>
これらの設定が同じである一般的なケースや、両方が C（またはそのエイリアスの POSIX）ではない場合には影響しません。しかし、LC_CTYPEが C で、LC_COLLATE が他のロケールである場合、誤った問い合わせ結果が発生し、文字列のインデックスが破損する可能性がありました。 このような設定を持つデータベースのユーザは、このアップデートをインストールした後、影響を受けるインデックスを再作成する必要があります。逆のケースで LC_COLLATE が C で、LC_CTYPE が他のロケールである場合、性能が低下しますが、実際のエラーは発生しませんでした。
</p>
<li>キー列の問い合わせの照合順序がパーティションキーの照合順序と一致しない場合は、パーティション同士の結合やグループ化を使用しないようになりました。 (Jian He, Webbo Han) (17)(16)(15)(14)(13)(12)</li>
<p>
問い合わせ内のキー列が登場する箇所に COLLATE句でパーティション定義と異なる照合順序を指定している場合に該当する可能性があります。このような実行計画では、誤った問い合わせ結果が生じる可能性がありました。
</p>
<li>NOT NULL 列の IS NULL 検査を FALSE 定数に変換した後のプランナの障害が回避されました。 (Richard Guo) (17)</li>
<p>
このバグは典型的には「ERROR: variable not found in subplan target lists」などのエラーを引き起こしました。
</p>
<li>引数に特定の配列関連の構造が含まれる SQL 関数をインライン化する際にプランナがクラッシュする可能性が回避されました。 (Tom Lane, Nathan Bossart) (17)</li>
<pre>（add は SQL言語の単純なユーザ定義関数）
db=# SELECT add(array_length(array_agg(i)::numeric[],1)::integer) FROM n;
</pre>
<p>バグ報告されたのは以下のようなユーザ定義SQL関数の呼び出しでした。</p>
<li>MERGE ... WHEN NOT MATCHED BY SOURCE アクションの誤った応答、または、「ERROR: wrong varnullingrels ...」が発生する可能性があり、修正されました。 (Dean Rasheed) (17)</li>
<p>
本障害で誤った問い合わせ結果が生じる可能性がありました。
</p>
<pre>（17.0 ではエラーになる使用法）
CREATE TABLE t (a int);
INSERT INTO t VALUES(1), (2);
CREATE VIEW v AS SELECT a FROM t WHERE EXISTS (SELECT 1 FROM t);

MERGE INTO v USING (SELECT * FROM generate_series(1,1)) AS s(a)
  ON s.a = v.a WHEN NOT MATCHED BY SOURCE THEN DELETE;

(発生していたエラー)
ERROR:  XX000: wrong varnullingrels (b) (expected (b 4)) for Var 5/1
LOCATION:  search_indexed_tlist_for_var, setrefs.c:2847
</pre>
<li>UNION ALL メンバーの問い合わせ出力をソートする必要があり、ソート列が式である場合に発生する可能性があった「ERROR: could not find pathkey item to sort」エラーが修正されました。 (Andrei Lepikhov, Tom Lane) (17)(16)(15)(14)(13)</li>
<li>B-tree の ScalarArrayOp を使うインデックススキャンでの稀な不具合が修正されました。 (Peter Geoghegan) (17)</li>
<p>
この種の実行プランを持つスクロール可能なカーソルが開始点まで巻き戻され、その後再び前方に実行された場合、誤った問い合わせ結果が生じる可能性がありました。
</p>
<p>
ScalarArrayOp は「indexed_col IN (1,2,3) や indexed_col = ANY ('{1,2,3}'::int[]) のような検索条件で使われます。
</p>
<li>問い合わせが「DO INSTEAD NOTIFY」の RULE によって書き換えられた場合に発生する「COPY (query) TO ...」でのアサート失敗や紛らわしいエラーメッセージ（「ERROR: COPY query must have a RETURNING clause」）が修正されました。 (Tender Wang, Tom Lane) (17)(16)(15)(14)(13)(12)</li>
<li>COPY の FORCE_NOT_NULL および FORCE_NULL オプションの検証が修正されました。 (Joel Jacobson) (17)</li>
<p>
誤った指定は適切に拒否されるようになりました。これまでは、COPY TO に対する FORCE_NULL、CSV以外の形式に対する FORCE_QUOTE などの、意味をなさない指定でもエラーになりませんでした。
</p>
<li>json_objectagg() 呼び出しに VOLATILE 関数が含まれている場合に発生するバックエンドプロセスのクラッシュが修正されました。 (Amit Langote) (17)(16)</li>
<li>並列ハッシュ結合中の偏ったデータの検出が修正されました。 (Thomas Munro) (17)(16)(15)(14)(13)(12)</li>
<p>
1つのパーティションにタプルが蓄積されすぎたため、ハッシュ結合の内側を再パーティショニングした後、パーティションのすべてのタプルが同じ子パーティションに入っているかどうかを確認します。 これは、すべてのタプルが同じハッシュ値を持っていることを示し、さらに再パーティションしても状況は改善されません。このチェックは場合によっては機能せず、無駄な再パーティショニングが繰り返され、最終的には（メモリ不足、ディスク領域不足などの）リソース枯渇エラーに至っていました。
</p>
<li>ALTER DATABASE SET を使用して、default_text_search_config などのサーチパスに基づく検索を必要とする設定パラメータを指定した時に発生していたクラッシュが、回避されました。 (Jeff Davis) (17)</li>
<li>パーティションテーブルに新しいインデックスを作成するときに、opclasses と照合順序の繰り返し検索が回避されました。 (Tom Lane) (17)</li>
<p>
これは主として一部の検索が制限された search_path で実行されたことにより、CREATE INDEX コマンドが pg_catalog 外のオブジェクトを参照した場合に予期せぬエラーを引き起こす問題がありました。この修正により、親パーティションインデックスのコメントが子インデックスにコピーされることも防止されます。
</p>
<p>
本障害で以下のようなメッセージが発生するケースが報告されました。
</p>
<pre>ERROR:  operator class "..._ops" does not exist for access method "..."
</pre>
<li>パーティションテーブルから、CREATE TABLE ... USING で指定された非組み込みアクセスメソッドへの、欠落した依存関係が追加されました。 (Michael Paquier) (17)</li>
<p>
アクセスメソッドに依存するテーブルが存在する場合、アクセスメソッドの削除はブロックされるべきですが、ブロックされていなかったため、その後に異常な動作が発生する可能性がありました。この修正は、この修正適用以降に作成されたパーティションテーブルの問題のみを防止することに注意してください。
</p>
<li>非 ASCII 文字を含むロケール名を許可しないようになりました。 (Thomas Munro) (17)(16)</li>
<p>
このようなロケール名は他の場所では使用されないため、これは Windows でのみ問題となります。 このような名前がどのようなエンコーディングで表現されるかが非常に不明確であるため、問題となります（ロケール自体が使用するエンコーディングを定義しているため）。最近のPostgreSQLのリリースでは、その混乱により Windows ランタイムライブラリでアボートが発生する可能性がありました。新しいエラーメッセージに遭遇した場合は、Windows Locale Builder を使用して ASCII のみの名前で新しい複製ロケールを作成するか、tr-TR のような BCP 47準拠のロケール名の使用を検討してください。
</p>
<li>serializable 分離レベルのトランザクションをコミットする際の競合状態が修正されました。 (Heikki Linnakangas) (17)(16)(15)(14)(13)(12)</li>
<p>
最近コミットされたトランザクションを誤って処理してしまい、アサート失敗、または「ERROR: could not access status of transaction」というエラーが発生する可能性がありました。
</p>
<li>2相コミットの状態を記録したファイルが残存してしまう COMMIT PREPARED の競合状態が修正されました。 (wuchengwen) (17)(16)(15)(14)(13)(12)</li>
<p>
並行する PREPARE TRANSACTION により、COMMIT PREPARED が完了したトランザクションについて、ディスク上の2フェーズコミットの状態を保持しているファイルを削除しない可能性がありました。すぐに悪影響が及ぶ可能性はありませんが、その後クラッシュが発生し、リカバリをすると「ERROR: could not access status of transaction」というエラーで失敗する可能性がありました。この場合、サービスを復元するためには残存したファイルを手動で削除する必要があります。
</p>
<li>VACUUM FULL 中に無効なトーストインデックスをスキップした後の無効なメモリアクセスが回避されるようになりました。 (Tender Wang) (17)(16)(15)(14)(13)(12)</li>
<p>
このコードパスでは、まだ再構築されていないインデックスを追跡するリストが適切に更新されなかったため、のちにアサート失敗やクラッシュが発生するリスクがありました。
</p>
<li>データを直接書き換える形で行われたカタログの更新が失われないよう修正されました。 (Tender Wang) (17)(16)(15)(14)(13)(12)</li>
<p>
通常の行更新では、トランザクションがロールバック可能なように、行の新しいバージョンが書き込まれます。ただし、特定のシステムカタログの更新は意図的にこのような形での更新は行わず、データを直接書き換えます。今回データを直接書き換える形での更新の効果が失われる可能性のある競合状態を修正されました。例えば、 pg_class.relhasindex をtrue に設定する更新が失われると、新しいインデックスの更新が妨げられ、それによりインデックスが破損する可能性がありました。
</p>
<li>リカバリの終了時にカタログキャッシュがリセットされるようになりました。 (Noah Misch) (17)(16)(15)(14)(13)(12)</li>
<p>
カタログキャッシュの古いデータを使用することで、データを直接書き換える形でのカタログの更新内容が失われないようになりました。
</p>
<li>割り込みを保留している間はパラレルクエリの使用を避けるようになりました。 (Francesco Degrassi, Noah Misch, Tom Lane) (17)(16)(15)(14)(13)(12)</li>
<p>
この状況は通常は発生しませんが、SQL 言語関数を B-tree サポートとして使用するなどのテストシナリオでは発生する可能性があります (これは実稼働環境での使用には遅すぎます)。発生した場合、無限に待機する可能性がありました。
</p>
<li>pg_cursors ビューに、まだ設定が完了していないポータルは含めないようになりました。 (Tom Lane) (17)(16)(15)(14)(13)(12)</li>
<p>
新しいカーソルの設定中に、このビューを検査するユーザー定義コードが呼び出される可能性があり、その場合、NULL ポインタの間接参照が発生します。設定が完了していないカーソルを除外するように pg_cursors ビューの定義を修正されました。
</p>
<li>列のデフォルト値の挿入を含むトランザクションをデコードするときに、「ERROR: unexpected table_index_fetch_tuple call during logical decoding」というエラーが発生しないよう修正されました。 (Takeshi Ideriha, Hou Zhijie) (17)(16)(15)(14)</li>
<p>
進行中のトランザクションのロジカルデコーディング中に、属性のデフォルトのトースト値を取得しながらトーストテーブルをスキャンしますが、このスキャン中に、システムテーブルのスキャンが進行中であることを示すフラグを初期化していませんでした。
</p>
<li>ロジカルデコーティングのメモリ消費量が削減されました。 (Masahiko Sawada) (17)(16)(15)(14)(13)(12)</li>
<p>
ロジカルデコーディングでは、長時間実行されるトランザクションの処理中に深刻なメモリの浪費が発生し、 メモリ不足に伴う障害が発生することがありました。この問題への対応として、論理レプリケーション中に受信したタプルデータを格納するために、より小さいデフォルトのブロックサイズを使用するようになりました。
</p>
<li>CALL が PL/pgSQL の EXCEPTION ブロック内にある時に、CALLステートメントの引数リストから呼び出される変動性分類がstableの関数の動作が修正されました。 (Tom Lane) (17)(16)(15)(14)(13)(12)</li>
<p>
以前の四半期リリースでの同様の修正と同じように、このケースでは、そのような関数に間違ったスナップショットが渡され、外部トランザクションの開始以降に変更された行の古い値が表示されることがありました。
</p>
<li>libpq の「keepalives」接続オプションを他の整数値オプションと同じ方法で解析するようになりました。 (Yuto Sasaki) (17)(16)(15)(14)(13)(12)</li>
<p>
他のケースとは異なり、オプション値の末尾の空白が拒否されていました。例えば、これは ecpg の使用時に問題となることが判明しています。
</p>
<li>ecpglib で不正な datetime 入力を解析する際の範囲外の読み取りをしないよう修正されました。 (Bruce Momjian, Pavel Nekrasov) (17)(16)(15)(14)(13)(12)</li>
<p>
実際に問題になることは通常なさそうですが、定数配列の開始直前の位置を読み取ろうとする可能性がありました。
</p>
<li>psql の \dコマンド(description コマンド)が 9.4 より前のサーバで再び動作するように修正されました。 (Tom Lane) (17)</li>
<p>
ACL (権限) 列の表示を伴うコマンドは、9.4 より前のバージョンには存在しない関数を使用していたため、非常に古い PostgreSQL サーバーでは失敗していました。
</p>
<li>psql の \watch コマンドで1ミリ秒未満の間隔が指定されている場合に起こるハングアップが回避されるようになりました。 (Andrey Borodin, Michael Paquier) (17)(16)</li>
<p>
1ミリ秒未満の間隔が指定された場合は、間隔 0 (実行間の待機なし)と同じように扱われるようになります。
</p>
<li>~/.pgpass内にレプリケーションパスワードが見つからない問題が修正されました。 (Tom Lane) (17)</li>
<p>
-d または --dbname が指定されていない場合、pg_basebackup とpg_receivewal は、データベース名フィールドに「replication」が含まれる ~/.pgpass のエントリと一致しませんでした。
</p>
<li>pg_combinebackup では、完全バックアップが格納されているはずのディレクトリに増分バックアップファイルが存在する場合にエラーを出すように修正されました。 (Robert Haas) (17)</li>
<li>pg_combinebackup では、二重スラッシュを含むファイル名を作成しないようになりました。 (Robert Haas) (17)</li>
<p>
機能上の問題は発生しませんでしたが、重複したスラッシュがエラーメッセージに表示され、混乱が生じる可能性がありました。
</p>
<li>vacuumdb および--jobsを指定した並列モードの reindexdb で一時テーブルとインデックスのインデックス再構築 試行することを避けるように修正されました。 (VaibhaveS, Michael Paquier, Fujii Masao, Nathan Bossart) (17)(16)(15)(14)(13)(12)</li>
<p>
他のセッションの一時テーブルのインデックス再構築は機能しませんが、一部のコードパスでそれらをスキップするチェックが欠落していたため、不要な障害が発生されました。
</p>
<li>ARM64 プラットフォーム上の誤った LLVM 生成コードが修正されました。 (Thomas Munro, Anthonin Bonnefoy) (17)(16)(15)(14)(13)(12)</li>
<p>
ARM プラットフォーム上で JIT コンパイルを使用すると、生成されたコードは32ビットを超える再配置距離をサポートできず、生成されたコードの配置が不適切になると、大容量メモリシステムでサーバークラッシュが発生する可能性がありました。
</p>
<li>プロセス開始時間 (time_t) が long 値に収まると想定していた数箇所が修正されました。 (Max Johnson, Nathan Bossart) (17)(16)(15)(14)(13)(12)</li>
<p>
long が 32 ビットのプラットフォーム (特に Windows) では、このコーディングは2038年以降に失敗します。ほとんどの失敗は表面的なものにすぎませんが、特にpg_ctl start がハングする可能性がありました。
</p>
<li>タイムゾーンデータファイルが tzdata release 2024b に更新されました。 (Tom Lane) (17)(16)(15)(14)(13)(12)</li>
<p>
この tzdata リリースでは、古い System-V 互換ゾーン名を変更して、対応する地理的ゾーンを複製します。たとえば、「PST8PDT」は「America/Los_Angeles」の別名になります。主な目に見える結果は、標準化されたタイムゾーンの導入前のタイムスタンプの場合、ゾーンは指定された場所のローカル平均太陽時を表すと見なされることです。たとえば、「PST8PDT」では、「1801-01-01 00:00」などの timestamptz 入力は、以前は「1801-01-01 00:00:00-08」とレンダリングされていましたが、現在は「1801-01-01 00:00:00-07:52:58」とレンダリングされます。
</p>
<p>
また、メキシコ、モンゴル、ポルトガルの歴史的修正が行われています。特に、Asia/Choibalsan は、主にこれらのゾーン間の違いが信頼できないデータに基づいていることが判明したため、現在では別のゾーンではなく、「Asia/Ulaanbaatar」の別名となっています。
</p>
<li>DETACH CONCURRENTLY とパーティションの即時削除が同時に発生すると、パーティション化されたテーブルに対するクエリでクラッシュや「ERROR: could not open relation with OID」というエラーが発生する可能性を回避するようになりました。 (Alvaro Herrera, Kuntal Gosh) (16)(15)(14)</li>
<li>アタッチ先のテーブルに、パーティションを参照する外部キーがある場合は、ALTER TABLE ATTACH PARTITION を許可しないように修正されました。 (Alvaro Herrera) (16)(15)(14)(13)(12)</li>
<p>
この構成はサポートされておらず、これを作成する他の方法でもすでに失敗するようになっています。
</p>
<li>後でプレーン結合に縮小される外部結合の下のサブクエリのフラット化に関連するパフォーマンスの低下が修正されました。 (Tom Lane) (16)</li>
<p>
PostgreSQL 16 では、クエリプルアップロジックの過度に楽観的な単純化により、以前のバージョンほど一部のクエリを最適化できていませんでした。
</p>
<li>大規模なハッシュインデックスのインデックス構築の第2段階でのキャンセルが許可されるようになりました。 (Tom Lane) (16)</li>
<p>
事前ソートが必要なほど大きい（maintenance_work_mem または shared_buffers よりも大きい）ハッシュインデックス構築する場合、最初のソートフェーズは中断可能ですが、挿入フェーズではループになり中断できませんでした。
</p>
<li>JSON オブジェクトのコンストラクターで、キーの一意性のチェックが修正されました。 (Junwang Zhao, Tomas Vondra) (16)</li>
<p>
1キロバイトより大きなオブジェクトを構築する際に、重複したキーを含むオブジェクトや不完全なオブジェクトが生成されたり、重複したキーが存在すると誤って報告されたりする可能性がありました。
</p>
<li>Bind および Execute プロトコルメッセージ処理の開始時に、クエリ ID を報告するようになりました。 (Sami Imseih) (16)(15)(14)</li>
<p>
以前はこれらの状態ではクエリ ID がわかりませんでしたが、報告されるようになりました。
</p>
<li>ネストが深すぎる XML 入力による libxml2 のスタックオーバーフローが防止されました。 (Tom Lane, with hat tip to Nick Wellnhofer) (16)(15)(14)(13)(12)</li>
<p>
以前利用していた xmlXPathCompile() は、2.13.4より前のバージョンでは再帰によるスタックオーバーフローが発生する可能性があったため、代わりに xmlXPathCtxtCompile() を使用するようされました。
</p>
<li>「XMLSERIALIZE(... INDENT)」が入力データに空白がある場合インデントされない問題が修正されました。 (Jim Jones) (16)</li>
<p>
空白で区切られたノードのインデントが失敗する問題が修正され、末尾に改行が追加されないようになりました。
</p>
<li>同時に実行される、述語または式を含むインデックスへの REINDEX CONCURRENTLY を無視した最適化しないようになりました。 (Michail Nikolaev) (16)(15)(14)</li>
<p>
通常、REINDEX CONCURRENTLY は、他のテーブルに対する他の REINDEX CONCURRENTLY 操作を待たない最適化を行いますが、 他の REINDEX CONCURRENTLY が述語または式を含むインデックスを処理している場合は、その中に他のテーブルにアクセスするユーザー定義コードが含まれている可能性があるため、この最適化は適用できませんでした。
</p>
<p>
修正前は、他の REINDEX CONCURRENTLY を待機していなかったため、競合状態が発生し、一貫性のない動作が発生する可能性がありました。
</p>
<li>名前が競合する場合の「ORDER BY」リストの誤った解析処理が修正されました。 (Tom Lane) (16)</li>
<p>
「SELECT」の「ORDER BY」項目が単なる識別子である場合、SQL92 との互換性のため、パーサーはまずそれを「SELECT」の出力列名として検索します。しかし、 ビューの定義で利用されているルールの処理は、SQL99 の解釈に従っており、そのような名前を出力ではなく入力列名であると想定しています。したがって、このような操作は推奨されないものの、ある列が「SELECT」の出力リストに名前を変更され、「ORDER BY」で使用される入力列と一致するように変更された場合、ビューの表示結果が不正になる可能性がありました。
</p>
<li>EXPLAIN における「failed to find plan for subquery/CTE」エラーが発生しないよう修正されました。 (Richard Guo, Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
この問題は、サブクエリの WHERE 条件が常に偽である場合など、実行計画からサブクエリが最適化によって完全に取り除かれた場合に、 サブクエリのRECORD 型出力のフィールドを表示しようとした際に発生することがありました。プラン内には元のフィールド名を識別するための情報が残らないため、代わりに「fN」という形式で N 番目のレコード列を表示するようになりました。
</p>
<li>生成列の型を変更するときに「USING」句を指定できないように修正されました。 (Peter Eisentraut) (16)(15)(14)(13)(12)</li>
<p>
「USING」句の出力は変換後の列に書き込まれるため、列の内容を指定している生成式の結果を破壊してしまうため、 「USING」句を指定した場合エラーとするようになりました。
</p>
<li>32 ビットマシンでの pg_stat_io ビューの誤った出力が修正されました。 (Bertrand Drouvot) (16)</li>
<p>
このようなハードウェアでは、stats_reset タイムスタンプ列にゴミが含まれていました。
</p>
<li>「Error： trailing junk after numeric literal」エラーメッセージが出力される誤ったエンコーディング処理が修正されました。 (Karina Litskevich) (16)(15)</li>
<p>
数値リテラルの後に識別子が続くことは許可しておらず、その間には空白が必要なため、{ interger }{ ident_start }のようなトークンパターンを利用していました。しかしながら、{ ident_start }にマルチバイト文字が続く場合が想定されていなかったため、クライアントへのレポートおよびログファイルにおいて、不正なエンコーディングとしてエラー出力されていました。
</p>
<li>論理レプリケーション適用ワーカーは、エラーまたは適用ワーカーのシャットダウン中に、レプリケーション起点が進行しないように修正されました。　 (Hayato Kuroda, Shveta Malik) (16)</li>
<p>
これにより、レプリケーション起点が進むとソースサーバーはそのデータを再度送信しなくなるため、トランザクションが失われる可能性がありました。
</p>
<li>TLS セッションチケット無効化のリグレッションを修正されました。 (Daniel Gustafsson) (16)(15)(14)(13)(12)</li>
<p>
TLSv 1.3のステートフル セッションチケットの送信を防止するための変更により、誤って TLSv 1.2のステートレスチケットの送信が再度有効になっていました。クライアントに TLS セッション再開( session resumption )がサポートしていると誤解されないようにすることを意図していましたが、一部のクライアントは依然としてサポートしていると考えていました。
</p>
<li>多数の ACL エントリを持つデータベースを削除するとき、「ERROR: wrong tuple length」が発生することがありましたが、回避されるようになりました。 (Ayush Tiwari) (16)(15)(14)(13)(12)</li>
<li>パラレルワーカーで session_authorization と role の設定が正しく行えるようになりました。 (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
動作中に変更可能な設定は「SET」句で変更できますが、パラレルワーカー内では上記の 2 つの設定が変更できませんでした。
</p>
<li>PL/pgSQL の CALL で特殊なケースで稀に発生する「cache lookup failed for function」エラーが発生する問題が修正されました。 (Tom Lane) (16)(15)(14)</li>
<li>ビッグエンディアンのハードウェア上でかつ OpenSSL が利用できない場合の MD5 の実装がスレッドセーフに修正されました。 (Heikki Linnakangas) (16)(15)(14)</li>
<p>
クライアント側で利用されるため、スレッドセーフではないことは問題がありました。
</p>
<li>ecpglib で pnstrdup() の使用を避けるようになりました。 (Jacob Champion) (16)(15)(14)(13)</li>
<p>
この関数はメモリ不足時に exit() を呼び出しますが、呼び出し元のコードは既に割り当て失敗を適切に処理しているため、この動作はライブラリとしては適切ではありませんでした。
</p>
<li>psql のメタコマンド \bind を繰り返し使用する際に発生していた psql のメモリリークが修正されました。 (Michael Paquier) (16)</li>
<li>テーブルの UNLOGGED/LOGGEDの設定と異なる永続性を持つ IDENTITY 列を管理するシーケンスの pg_dump の処理が修正されました。 (Tom Lane) (16)(15)</li>
<p>
v15 以降、テーブルが UNLOGGED のときに IDENTITY 列を管理するシーケンスだけを LOGGED に設定したり、その逆を行ったりすることが可能になっています。ただし、バイナリアップグレードモードではその状況を再現する pg_dump が失敗し、そのようなシーケンスが存在すると pg_upgrade は失敗していました。シーケンスの永続性が作成時に正しく設定できるように、「ADD/ALTER COLUMN GENERATED AS IDENTITY」に新しいオプションを導入して修正されました。したがって、このようなシーケンスを含むデータベースからのダンプは、このマイナーバージョン以降のサーバーにのみロードできます。
</p>
<li>pg_rewind のデバッグ出力に、ソースタイムライン履歴を含めるように修正されました。 (Heikki Linnakangas) (16)(15)(14)(13)(12)</li>
<p>
これは当初の意図でしたが、ソース履歴が常に空として出力されていました。
</p>
<li>contrib/pageinspect および contrib/pgstattuple 関連の関数で、シーケンス関係の検査を許可するようになりました。 (Nathan Bossart, Ayush Vatsa) (16)(15)(14)(13)(12)</li>
<p>
これは以前は許可されていましたが、テーブルに対するデフォルト以外のアクセスメソッドの導入時に機能しなくなっていました。
</p>
<li>Windows 上での Strawberry Perl を使用したビルドが修正されました。 (Andrew Dunstan) (16)(15)(14)(13)(12)</li>
<li>Windows (特に pg_rewind )の ジャンクションポイントの誤動作が修正されました。 (Andrew Dunstan) (16)(15)(14)(13)(12)</li>
<li>MinGW でビルドするときに発生する、「missing declaration for inet_pton」というコンパイラの警告またはエラーを防止するようになりました。(Thomas Munro, Andrew Dunstan) (15)</li>
<li>PostgreSQL の RPM パッケージをビルドする際に発生する、「Error: nothing provide perl(PostgreSQL::Test::Utils)」が防止されるようになりました。 (Noah Misch) (14)(13)(12)</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 13.16 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/13-16/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Thu, 29 Aug 2024 00:11:33 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 13]]></category>
		<category><![CDATA[PostgreSQL 13.15]]></category>
		<category><![CDATA[PostgreSQL 13.16]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=15025</guid>

					<description><![CDATA[このリリースは 13.16 からの修正リリース（2024年 8月 8日リリース）です。 13.X からのアップデートではダンプ、リストアは不要です。 ただし、13.14 よりも前のバージョンからアップデートする場合には、 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 13.16 からの修正リリース（2024年 8月 8日リリース）です。<br />
13.X からのアップデートではダンプ、リストアは不要です。</p>
<p>ただし、13.14 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/13-14/" rel="noopener">13.14 のリリース情報</a>も参照してください。</p>
<p><span id="more-15025"></span></p>
<h3>PostgreSQL 13.15 から 13.16 への変更点</h3>
<p>16.4、15.8、14.13、13.16、12.20 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>pg_dump 実行時の権限のないコードの実行が防止されました。  (Masahiko Sawada) (16)(15)(14)(13)(12)</li>
<p>
永続オブジェクトの作成、削除ができる攻撃者により、SQLコードのインジェクションが可能でした。そのコードは pg_dump を起動するロール（しばしばスーパーユーザです）の権限で、並列 pg_dump のセッションから実行されます。シーケンスのようなオブジェクトを悪意のコードを実行するビューや外部テーブルで置き換えることで、攻撃が行われます。これを防ぐため、ビルトインでないビューの展開および外部テーブルへのアクセスを無効にできる新たな設定パラメータ restrict_nonsystem_relation_kind が導入されました。デフォルトは ''（空文字列）で、カンマ区切りで view や foreign-table を指定します。この設定が pg_dumpコマンド内で SET で指定されるようになります。攻撃を防ぐにはサーバと pg_dumpコマンドの両方のアップデートが必要です。(CVE-2024-7348)
</p>
<li>Merge Anti Join を使う実行プランから誤った問い合わせ結果が生じることがあり、修正されました。  (Richard Guo) (16)</li>
<p>
内側のリレーションが制約でユニークな結合キーを持つと分かっている場合に、外側のリレーションに結合キーの重複した行があるとき、マージが誤動作を起こす可能性がありました。
</p>
<pre>
（誤動作例）
db1=# CREATE TABLE t2 (a int UNIQUE, b int);
db1=# INSERT INTO t2 SELECT g, g % 100 FROM generate_series(1,1000) g;
db1=# CREATE INDEX ON t2 (b);
db1=# ANALYZE t2;
db1=# SET enable_hashjoin TO off;
db1=# SET enable_nestloop TO off;
db1=# SELECT * FROM t2 t2out WHERE NOT EXISTS
        (SELECT 1 FROM t2 t2in WHERE t2in.b = t2out.a) AND t2out.b < 2;

→ Nested Loop Anti Join や Hash Right Anti Join の場合には正しく動作するが、
   Merge Right Anti Join を使った実行プランでは少ない件数が返る。
</pre>
<li>VACUUM での無限ループが防止されました。  (Melanie Plageman) (16)(15)(14)</li>
<p>
長時間実行中のトランザクションを伴う切断されたスタンバイサーバがプライマリサーバに再接続した後に、プライマリでの VACUUM 処理が、どのタプルが除去可能かについて混乱する可能性があり、その結果、無限ループに陥ることがありました。
</p>
<li>以前に継承ツリーの子テーブルを持っていたテーブルをパーティションとしてアタッチした場合に、後で生じる障害が修正されました。  (&Aacute;lvaro Herrera) (16)(15)(14)(13)(12)</li>
<p>
アサート失敗が報告されました。アサートを無効にした実稼働むけビルドでは、クラッシュや誤動作が生じる可能性があります。
</p>
<pre>
（障害発生例）
db1=# CREATE TABLE t_inh_p (a int);
db1=# CREATE TABLE t_inh_c () INHERITS (t_inh_p);
db1=# DROP TABLE t_inh_c;
db1=# CREATE TABLE pt (a int) PARTITION BY LIST (a);
db1=# ALTER TABLE pt ATTACH PARTITION t_inh_p FOR VALUES IN (1);
db1=# INSERT INTO t_inh_p VALUES (1);
db1=# UPDATE t_inh_p SET a = 2 WHERE a = 1;
→ ここでアサート失敗が生じる（正常動作はパーティション制約違反のエラー）
</pre>
<li>一貫性に欠けた、インデックスによる制約を伴うパーティションテーブルへのALTER TABLE .. DETACH PARTITION .. での障害が修正されました。  (&Aacute;lvaro Herrera, Tender Wang) (16)(15)(14)(13)(12)</li>
<p>
パーティションテーブル（親テーブル）に制約と関連付かないインデックスがあって、そのパーティション（子テーブル）に同等の制約のインデックスがある場合、パーティションをデタッチするときにアサート失敗が生じたり、システムテーブル pg_constraint の coninhcount列が誤った値になりました。
</p>
<pre>
db1=# CREATE TABLE pt5 (a int) PARTITION BY LIST (a);
db1=# CREATE TABLE p5 PARTITION OF pt5 FOR VALUES IN (1);
db1=# ALTER TABLE p5 ADD PRIMARY KEY (a);
db1=# CREATE UNIQUE INDEX ON pt5 (a);
db1=# ALTER TABLE pt5 DETACH PARTITION p5;
→ ここでアサート失敗か、以下が 0 ではなく -1 になる。
db1=# SELECT coninhcount FROM pg_constraint WHERE conname = 'p5_pkey';
</pre>
<li>ALTER TABLE .. DETACH PARTITION .. CONCURRENTLY と並行するパーティションプルーニングの調整について修正されました。  (&Aacute;lvaro Herrera) (16)(15)(14)</li>
<p>
エグゼキュータはプラン作成と実行の間でパーティションがデタッチされないと想定していましたが、CONCURRENTLY指定を使う場合にはその前提は成り立ちません。パーティションテーブルに対する問い合わせ実行で、そのようなタイミングのときに、アサート失敗や以下のようなエラーが発生しました。
</p>
<pre>
ERROR:  missing relpartbound for relation ..
ERROR:  could not match partition child tables to plan elements
</pre>
<li>パーティションテーブルから最後のパーティション（子テーブル）がDROP された後、pg_class.reltuples を正しく 0 に更新するようになりました。(Noah Misch) (16)(15)(14)</li>
<p>
パーティションが無くなったパーティションテーブルに対する最初の ANALYZE でrelhassubclass = f の変更をするときに reltuples = 0 の変更が失われていました。
</p>
<li>プロシージャの多様OUT引数の処理が修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
SQL の CALL文は多様OUT引数に対して正しいデータ型を解決できず、「ERROR:  cannot display a value of type anyelement」などのエラーや、クラッシュを引き起こしました。
</p>
<p>
なお、PL/pgSQL 内の CALL は問題ありません。
</p>
<pre>
（障害動作例）
db1=# CREATE PROCEDURE pro1 (i1 IN anynonarray, o1 OUT anynonarray)
        LANGUAGE sql AS $$ SELECT i1; $$;
db1=# CALL pro1('aa'::text, NULL);
ERROR:  cannot display a value of type anynonarray
</pre>
<li>PL/pgSQL で CALL 文の引数リストから呼び出された STABLE関数の振る舞いが修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
CALL が、トランザクションブロック内のアトミックなコンテキストで実行された場合に、誤って外側トランザクションの開始時点のスナップショットが STABLE関数に渡されて、古い値が参照されていました。
</p>
<pre>
（誤動作例）
db1=# CREATE TABLE t9 AS SELECT 0 AS x;
db1=# CREATE FUNCTION f_get_x() RETURNS int STABLE LANGUAGE plpgsql AS
      $$ DECLARE r int; BEGIN SELECT x INTO r FROM t9; RETURN r; END; $$;
db1=# CREATE PROCEDURE f_print_x(x int) LANGUAGE plpgsql AS 
      $$ BEGIN RAISE NOTICE 'f_print_x(%)', x; END; $$;
db1=# BEGIN;
db1=# DO $$ BEGIN
            UPDATE t9 SET x = x + 1;
            RAISE NOTICE 'f_get_x(%)', f_get_x();
            CALL f_print_x(f_get_x());
            UPDATE t9 SET x = x + 1;
            RAISE NOTICE 'f_get_x(%)', f_get_x();
            CALL f_print_x(f_get_x());
            END $$;
NOTICE:  f_get_x(1)
NOTICE:  f_print_x(0)   （← 正しくは 1）
NOTICE:  f_get_x(2)
NOTICE:  f_print_x(0)   （← 正しくは 2）
db1=# ROLLBACK;
</pre>
<li>time型、timetz型に対する ISO-8601拡張時刻書式の入力について修正されました。  (Tom Lane) (16)</li>
<p>
'T12:34:56' のような書き方を再び許容するようになりました。PostgreSQL 15.x 以前では受け入れられていましたが、16.0 以降で「ERROR:  invalid input syntax for type ...」のエラーになっていました。
</p>
<li>money型の計算で整数オーバーフローを検知するようになりました。  (Joseph Koshakow) (16)(15)(14)(13)(12)</li>
<p>
money型に対する算術関数はこれまでオーバーフロー検査をしていませんでした。そのため、オーバーフローする場合に誤った問い合わせ結果が生じていました。
</p>
<pre>
（誤動作例）
db1=# SELECT '92233720368547758.07'::money + '0.01'::money;
          ?column?
-----------------------------
 -$92,233,720,368,547,758.08
(1 row)
→ 修正後は「ERROR:  money out of range」エラーが出る。
</pre>
<li>round(numeric, int) および trunc(numeric, int) 関数で、スケール引数の過剰な制限が修正されました。  (Dean Rasheed) (16)(15)(14)(13)(12)</li>
<p>
これまでスケール引数は（文書に記載なく）正負 2000桁までに制限されていて、それを越える場合には、誤った問い合わせ結果が返っていました。numeric型の上限に合わせた桁数を上限とするように修正されました。
</p>
<pre>
（誤動作例 - 本来全て「1000」にならないといけない）
db1=# SELECT substr(round(1.234e1999, -1999)::text, 1, 4);
 substr
--------
 1000
(1 row)

db1=# SELECT substr(round(1.234e2000, -2000)::text, 1, 4);
 substr
--------
 1000
(1 row)

db1=# SELECT substr(round(1.234e2001, -2001)::text, 1, 4);
 substr
--------
 1200
(1 row)
</pre>
<li>最小 bigint値に対する pg_size_pretty() の出力が修正されました。  (Joseph Koshakow) (16)(15)</li>
<pre>
（誤動作ケース - 期待される正しい出力は「-8192PB」）
db1=# SELECT pg_size_pretty('-9223372036854775808'::bigint);
       pg_size_pretty
----------------------------
 -9223372036854775808 bytes
(1 row)
</pre>
<li>スタンバイサーバ上の UNLOGGED のシーケンスと、他セッションの一時シーケンスについて、pg_sequence_last_value() が ERROR を起こさないように修正されました。  (Nathan Bossart) (16)(15)(14)(13)(12)</li>
<p>
このような場合に、これからは NULL を返すようになります。本関数は pg_sequences ビューの中で使われるもので文書化されていません。
</p>
<pre>
（プライマリサーバで実行 - これで UNLOGGED のシーケンスが作られる）
db1=# CREATE UNLOGGED TABLE t14 (id serial);

（スタンバイサーバで実行 - 修正前バージョンではエラーになる）
db1=# SELECT * FROM pg_sequences ;
ERROR:  could not open file "base/18077/18108": No such file or directory
</pre>
<li>websearch_to_tsquery() で無視される演算子のパースが修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
マニュアルでは websearch_to_tsquery() の入力中の記号は、ダッシュ(-) と引用符(") の特別な場合を除き無視されることになっています。しかしながら、括弧といくつかの記号が or の直前に現れた場合、or が演算子ではなく or という単語として扱われる動作がありました。
</p>
<pre>
（or は引用符で囲わない限り演算子）
db1=# select websearch_to_tsquery('simple', 'cat or dog');
 websearch_to_tsquery
----------------------
 'cat' | 'dog'
(1 row)

（誤動作例 - 括弧があると or が演算子として扱われない）
db1=# select websearch_to_tsquery('simple', '(tom cat) or dog');
     websearch_to_tsquery
------------------------------
 'tom' & 'cat' & 'or' & 'dog'
(1 row)
</pre>
<li>新たな配列次元を計算するときの整数オーバーフローを検出できるようになりました。  (Joseph Koshakow) (16)(15)(14)(13)(12)</li>
<p>
以下の INSERT が正しくエラーになるようになりました。
</p>
<pre>
（修正前バージョンでは a = '{}' で行が挿入される）
db1=# CREATE TABLE t16 (a int[]);
db1=# INSERT INTO t16 (a[-2147483648:2147483647]) VALUES ('{}');
ERROR:  array size exceeds the maximum allowed (134217727)
</pre>
<p>
バージョン 16.1、15.5、14.10、13.13、12.17、11.22 で修正された、CVE-2023-5869 の件と似ていますが、本障害では配列は空で終わるので無害です。
</p>
<li>ライブラリ関数 strnxfrm() の移植性に欠ける使い方が修正されました。  (Jeff Davis) (16)</li>
<p>
一部のコードパスでは、非決定的な照合順序の使用において「ERROR:  pg_strnxfrm() returned unexpected result」のエラーが発生する可能性がありました。
</p>
<li>TOAST化されたフィールドを展開するときに、新たなカタログキャッシュエントリが古くなったことを検知するようになりました。  (Noah Misch) (16)(15)(14)(13)(12)</li>
<p>
TOASTテーブルを持つシステムカタログにインプレース更新を行う場合に問題が発生します。該当するのは pg_database だけです。pg_database の情報を使う SQL (例えば GRANT .. ON DATABASE .. など) で古い情報が使われてしまう可能性がありました。
</p>
<li>DEFAULT を伴う INSERT について、ビューの列が更新可能であるかを正しく検査するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
対象の列が更新不能である場合、その旨のエラーを出すべきですが、検査が漏れており、後のコードから「ERROR:  attribute number N not found in view targetlist」という意味が理解しにくいエラーメッセージが生じていました。
</p>
<pre>
（修正前の動作例）
db1=# CREATE TABLE t19 (id int);
db1=# CREATE VIEW v19 AS SELECT id, id * 2 AS c_2id FROM t19;
db1=# INSERT INTO v19 VALUES (1, 2);
ERROR:  cannot insert into column "c_2id" of view "v19"
DETAIL:  View columns that are not columns of their base relation are not updatable.
db1=# INSERT INTO v19 VALUES (1, DEFAULT);
ERROR:  attribute number 2 not found in view targetlist
</pre>
<li>不正な再帰問い合わせに対して、エラー報告内容が改善されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
これまで、WITH RECURSIVE の問い合わせで UNION の 2つ目の枝に自己参照が無いけれども ORDER BY のような別の場所に自己参照がある場合に、役に立たない内部的なエラーメッセージが出ていました。
</p>
<pre>
（修正前の動作例）
db1=# WITH RECURSIVE x(n) AS (WITH x1 AS (SELECT 1 FROM x)
        SELECT 0 UNION SELECT * FROM x1) SELECT * FROM x;
ERROR:  missing recursive reference
（→ 修正後のメッセージは以下）
ERROR:  recursive reference to query "x" must not appear within a subquery

db1=# WITH RECURSIVE x(n) AS (
        SELECT 0 UNION SELECT 1 ORDER BY (SELECT n FROM x)) SELECT * FROM x;
ERROR:  missing recursive reference
（→ 修正後のメッセージは以下）
ERROR:  ORDER BY in a recursive query is not implemented
</pre>
<li>ALTER TABLE .. SET LOGGED/UNLOGGED で、テーブルが所有するシーケンスにもロック取得するように修正されました。  (Noah Misch) (16)(15)</li>
<p>
このコマンドは（通常は serial型の列により）テーブルに紐づくシーケンスについても LOGGED と UNLOGGED の切り替えを行いますが、シーケンスについてロック取得されていませんでした。このため、同時に実行される nextval() の結果が失われる可能性がありました。
</p>
<li>キューに入っていた AFTER トリガが実行時には無くなっていた場合に、エラーを出さないようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
トランザクションで遅延された AFTERトリガを発生させる操作を実行して、その後、トリガ実行に至る前にそのトリガが DROP された場合に該当します。これまでは「ERROR:  could not find trigger NNNN」エラーを出していましたが、動作が変更されました。この場合は何もしない方が良いと判断されました。
</p>
<li>テーブルが削除されたときに、列単位の権限についてシステムカタログ pg_init_privs のエントリの削除に失敗していたものが、修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
ある拡張が作成したテーブルの列単位権限を GRANT した場合に、関連する pg_init_privs のエントリが拡張を削除した後にも残っていました。これはテーブルの OID が再利用されない限りは無害です。pg_init_privs に残ったエントリは、OID が一致するテーブルの pg_dump 出力に影響を与える可能性があります。
</p>
<li>望ましいインデックスが式や述語を持つときに、ON CONFLICT に対する競合解決インデックスの選択が修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
問い合わせ（INSERT）が更新可能ビューを通してターゲットテーブルにON CONFLICT を用いたアクセスする場合、利用可能なインデックスがある場合でも、それが無いというエラーが生じていました。
</p>
<pre>
（エラー発生例）
db1=# CREATE TABLE t24 (js jsonb);
db1=# CREATE UNIQUE INDEX ON t24 ((js ->> 'key'));
db1=# CREATE VIEW v24 AS SELECT * FROM t24;
db1=# INSERT INTO v24 VALUES ('{"key": "value"}')
        ON CONFLICT ((js ->> 'key')) DO NOTHING;
ERROR:  there is no unique or exclusion constraint matching the ON CONFLICT specification
</pre>
<li>ALTER TABLE で他セッションの一時テーブルを書き換えることが禁止されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
権限チェックにより、通常は他セッションの一時テーブルの行を参照・更新することは防止されますが、ALTER TABLE で定義変更をすることは可能でした。永続テーブルを継承する一時テーブルを作ることで、スキーマ pg_temp_NNN を指定することなく、他セッション一時テーブルの ALTER TABLE を試みることができてしまいました。
</p>
<pre>
（現象再現例）
db1=> CREATE TABLE t25(i int);
db1=> CREATE TEMP TABLE t25tt () INHERITS (t25);

（別セッションで実行）
db1=> ALTER TABLE t25 ADD c text;
ERROR:  could not open file "base/18077/18239": No such file or directory
　→ アサート有のビルドならアサート失敗／列追加に成功してしまう場合もある

（修正後のエラー）
ERROR:  cannot alter temporary tables of other sessions
</pre>
<li>CREATE TABLE ... LIKE ... STATISTICS での式の拡張統計の処理が修正されました。  (Tom Lane) (16)(15)(14)</li>
<p>
このような CREATEコマンドは、統計情報の式の列参照で列番号を適切に調整できませんでした。その結果、無効な統計オブジェクトが作られて、後で問題が生じました。典型的には元テーブルが削除された列を持っていて、列番号の付け直しが必要になる場合です。
</p>
<pre>
（障害発生例）
db1=# CREATE TABLE t26s (a text, b text, c text);
db1=# CREATE STATISTICS es26 ON (a || c) FROM t26s;
db1=# ALTER TABLE t26s DROP COLUMN b;
db1=# CREATE TABLE t26t (LIKE t26s INCLUDING STATISTICS);
db1=# \d t26t
ERROR:  invalid attnum 3 for relation "t26t"
</pre>
<li>min() または max() 集約から生成された副問い合わせの再計算に失敗していたものが修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
一部の場合では、外側の問い合わせのある行で計算された集約結果が、後の行でそうすべきでないときに再利用されるおそれがありました。これは外側の問い合わせがハッシュ集約で実装された DISTINCT を用いているときだけ起きると見られていますが、他の場合もありえます。
</p>
<p>
本障害により誤った問い合わせ結果が生じます。
</p>
<pre>
（誤動作例 - min も 1、2、3 となるのが正しい結果）
db1(5432)=# CREATE TABLE t27 (f1 int4);
db1(5432)=# INSERT INTO t27 VALUES (1),(2),(3);
db1(5432)=# SET enable_sort TO off;
db1(5432)=# SELECT f1, (SELECT DISTINCT min(t27in.f1) FROM t27 t27in
              WHERE t27in.f1 = t27out.f1) FROM t27 t27out;
 f1 | min
----+-----
  1 |   1
  2 |   1
  3 |   1
(3 rows)
</pre>
<li>位置パラメータでアンダースコア(_) が再び禁止されました。  (Erik Wienhold) (16)</li>
<p>
バージョン 16.0 で整数リテラルがアンダースコアを含むことが可能になりました。この変更で「$1_234」などを単一トークンとして扱うようになりましたが、これは正しく機能しませんでした。位置パラメータのシンボルは $ とそれに続く数字のみに戻されました。
</p>
<li>JIT でインライン化されたバックエンド関数がエラーを出すときのクラッシュが回避されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
エラー状態は（エラー位置を示す文字列のために）JITコンパイルされたコードを持つ動的にロードされたモジュールへのポインタを含むことができます。一部のコードパスでモジュールはエラー報告が処理される前にモジュールがアンロードされる可能性があり、エラー位置を示す文字列にアクセスがあったとき、SIGSEGV がもたらされました。
</p>
<li>libxml2 ライブラリ バージョン 2.13.x での振る舞い変更に対応しました。  (Erik Wienhold, Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
報告されたエラーがそれだけでない限り、libxml2 からの「chunk is not well balanced」エラーを抑止するようになりました。これにより 2.13.x とそれ以前のバージョンとのエラー報告の一貫性を保ちます。以前のバージョンではこのメッセージは冗長であったり、完全に間違っていたりしたので、2.13.x では報告されるケースの数が大幅に減りました。
</p>
<li>ホットスタンバイサーバを起動するときに、準備されたトランザクションのサブトランザクションの処理が修正されました。  (Heikki Linnakangas) (16)(15)(14)(13)(12)</li>
<p>
シャットダウン時のチェックポイント の WALレコードでスタンバイのリプレイを開始すると、プライマリで準備されているがまだコミットされていないトランザクションは、進行中であると正しく認識されます。しかし、サブトランザクション（セーブポイントまたは PL/pgSQL の例外ブロックで生じる）については考慮されず、中止されたものとして扱われていました。
</p>
<p>
これにより、準備されたトランザクションが後でコミットされた場合に、コミットされた内容が REPEATABLE READ 分離レベルの別トランザクションにおいて途中から参照可能になる、といった不整合が発生していました。
</p>
<li>論理レプリケーションスロットの誤った初期化が防止されました。  (Masahiko Sawada) (16)(15)(14)(13)(12)</li>
<p>
場合によっては、WALストリーム内のレプリケーションスロットの開始ポイントがトランザクション内のポイントに設定され、アサート失敗が発生したり、デコード結果が不正確になったりすることがありました。
</p>
<li>レプリケーションスロットの作成と削除中に「ERROR:  can only drop stats once」エラーが生じることが回避されました。  (Floris Van Nee) (16)(15)</li>
<p>
同時にスロットの作成・削除を行うとタイミングによって現象が発生しました。アサートが有効なビルドではアサート失敗も発生します。
</p>
<li>論理レプリケーションで WAL sender のリソースリークが修正されました。  (Hou Zhijie) (16)(15)</li>
<p>
パーティションテーブル（親テーブル）が、列が追加されている等、物理的に異なる行タイプのパーティション（子テーブル）を持つとして、そのようなパーティションテーブルの変更をパブリッシュするときに、wal sender プロセスでメモリリークが生じました。
</p>
<li>NOTIFY または sinval割り込み（共有キャッシュ無効化）を処理した後のメモリリークを回避するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
これらのイベントの処理関数では現在メモリコンテキストを TopMemoryContext に切り替える可能性があり、その結果、切り替え前に割り当てられたデータについて、セッション存続期間でのリークが発生しました。少なくとも、受信した問い合わせと Bind メッセージに付加されたパラメータのエンコード変換でリークが観察されました。
</p>
<li>実行時統計情報に使用される共有メモリブロックの参照カウントの漏洩が防止されるようになりました。  (Anthonin Bonnefoy) (16)(15)</li>
<p>
統計情報の共有メモリにアタッチされた新しいバックエンドプロセスは参照カウントを増加させましたが、終了時にカウントを減少させていませんでした。2^32 セッションが作られた後、参照カウントが 0 にオーバーフローして、その後のバックエンドプロセス起動が「ERROR:  could not attach to ...」エラーで失敗する可能性がありました。
</p>
<li>マルチトランザクションの SLRU ログを切り捨てるときの、デッドロックとアサート失敗の発生が防止されました。  (Heikki Linnakangas) (16)(15)(14)</li>
<p>
SLRUセグメントを削除しようとするプロセスは、checkpointerプロセスとデッドロックする可能性がありました。
</p>
<li>Windowsソケットで入力終了イベントが失われる可能性を回避するようになりました。  (Thomas Munro) (16)(15)(14)(13)(12)</li>
<p>
Windowsは接続のリモート側が切断された後に FD_CLOSE イベントを1回だけ報告します。タイミングが悪いと、その報告を見逃し、さらに入力を期待して無期限に、または少なくともタイムアウトが経過するまで待機する可能性がありました。
</p>
<p>
結果としてクライアント側が切断したことの検知が遅れて、「FATAL:  sorry, too many clients already」などが生じる原因となりました。
</p>
<li>JSON 解析のエラー報告における、不完全なバイトシーケンスのバッファオーバーラン読み出しが修正されました。  (Jacob Champion) (16)(15)(14)(13)</li>
<p>
最後のバイトが不完全なマルチバイト文字で構成されている場合、入力バッファの末尾から数バイト離れる可能性がありました。通常は無害ですが、原理的にはクラッシュを引き起こす可能性がありました。
</p>
<li>OpenSSL でステートフルTLSセッションチケットの作成が無効になりました。  (Daniel Gustafsson) (16)(15)(14)(13)(12)</li>
<p>
セッションチケットの受信が TLSセッション再開がサポートされていることを意味すると考えるクライアントで発生するおそれのある障害を、これにより回避できます。
</p>
<p>
これまでも無効にしていましたが、OpenSSL 1.1.1 以降の TLSv1.3 に対応した無効化の指定が必要でした。
</p>
<li>PL/pgSQL の「単純な式」を再計画するときに、それがまだ単純であることを確認するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
参照された関数を削除して集約として再作成するなど、大がかりな変更を行った際に、「ERROR:  unexpected plan node type ..」などの予期せぬエラーが発生する可能性がありました。
</p>
<pre>
（障害動作例 - 単純なSQL関数を PL/pgSQL関数から呼び出す）
db1=# CREATE FUNCTION f41() RETURNS int LANGUAGE sql AS $$ SELECT 1 + 1 $$;
db1=# CREATE FUNCTION f41caller() RETURNS int LANGUAGE plpgsql AS $$
        DECLARE x int; BEGIN x := f41simple(); RETURN x; END $$;
db1=# SELECT f41caller();
 f41caller
-----------
         2
(1 row)

（単純な関数を作り直して同セッション内で再度実行するとエラーになる）
db1=# DROP FUNCTION f41;
db1=# CREATE FUNCTION f41() RETURNS SETOF int LANGUAGE sql AS
        $$ SELECT g FROM (VALUES (1),(2)) AS g (g) LIMIT 1; $$;
db1=# SELECT f41caller();
ERROR:  unexpected plan node type: 311
CONTEXT:  PL/pgSQL function f41caller() line 1 at assignment
</pre>
<li>PL/pgSQL で、アンダースコア（_）を含む整数範囲の処理が修正されました。  (Erik Wienhold) (16)</li>
<p>
PostgreSQL 16.x では整数リテラルにアンダースコアを含めることができますが、PL/pgSQL は「FOR i IN 1_001..1_003」ような文を正しく処理できていませんでした。
</p>
<pre>
（エラー発生例 - 「1_001」と「..」の間に空白がない場合にエラーとなる）
db1=# CREATE FUNCTION test(cnt int) RETURNS int LANGUAGE plpgsql AS $$
      DECLARE i integer;
      BEGIN
        FOR i IN 1_001..1_005 LOOP
          cnt := cnt + 1;
        END LOOP;
        RETURN cnt;
     END; $$;
ERROR:  syntax error at or near "1_001."
</pre>
<li>PL/Python で再帰的に RECORD を返す関数の処理が修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
AS句で異なる列定義リストを渡す関数内で、その関数の再帰的な呼び出しを行った場合、内部呼び出しによって外部呼び出しの返す行型を上書きしてしまうため、エラーが発生しました。
</p>
<pre>
（障害発生例 - 内部で int型列のレコードを返す再帰呼び出しがある）
db1=# CREATE FUNCTION f43(t text) RETURNS record LANGUAGE plpython3u AS $$
      if t == "text":
          plpy.execute("SELECT * FROM f43('int') AS (a int)");
          return { "a": "x" }
      elif t == "int":
          return { "a": 1 }
      $$;

db1=# SELECT * FROM f43('text') AS (a text);
ERROR:  invalid input syntax for type integer: "x"
CONTEXT:  while creating return value
PL/Python function "f43"
→ 修正後は列名a、値「x」を持つレコードが返る
</pre>
<li>PL/Python で再帰的なトリガーの呼び出し中に TD辞書を破損しないように処理が修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
PL/Python のトリガーによって別のトリガーが呼び出された場合、内側のトリガー用に作成された TD辞書によって外側のトリガーの TD辞書が上書きされてしまっていました。
</p>
<p>
TD辞書はトリガとして PL/Python 関数を使用した場合に、関連する値を格納するために使われます。
</p>
<li>PL/Tcl で、タプルを返す関数の結果で無効なリスト構文を報告する問題が修正されました。  (Erik Wienhold, Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
これにより、クラッシュが生じたり、以前の Tclエラーを指す誤ったコンテキスト情報が出力されたりする可能性がありました。
</p>
<li>libpq でライブラリ関数 strerror() の非スレッドセーフ利用を回避しました。  (Peter Eisentraut) (16)(15)(14)(13)(12)</li>
<p>
マルチスレッドアプリケーションにおいて、OpenSSL から返るエラーメッセージがおかしくなる可能性がありました。
</p>
<pre>
（以下のようにメッセージがエラーコード表示になってしまうケースが報告された）
FATAL:  could not load root certificate file "root_ca.crl": SSL error code 2147483650
</pre>
<li>pg_dump でバイナリアップグレード処理中のメモリリークが回避されました。  (Daniel Gustafsson) (16)(15)</li>
<p>
pg_dump で --binary-upgrade オプションを指定した場合に該当します。通常、このオプションを使用するのは pg_upgrade コマンドだけです。
</p>
<li>「pg_restore -l」が依存している TOCエントリを正しく報告するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
pg_restore の「-l」が「-n」や「-N」などの選択的なリストアのオプションと共に指定された場合、コメントなど依存しているオブジェクトが、実際にはダンプに含まれていてリストアされるものであっても、TOC エントリ一覧から省かれていました。
</p>
<li>contrib/pg_stat_statements が SQL言語の関数内のユーティリティ命令を識別できるようになりました。  (Anthonin Bonnefoy) (16)</li>
<p>
SQL言語の関数のエグゼキュータは、ユーティリティ命令（SELECT/INSERT/UPDATE/DELETE/MERGE 以外）に対して計算したクエリID を伝えそこなっていました。
</p>
<li>contrib/postgres_fdw で「ERROR:  cursor can only scan forward」エラーが回避されました。  (Etsuro Fujita) (16)(15)</li>
<p>
リモートサーバが PostgreSQL 15 以降であって、リモートの単純ではないビューに対して作った外部テーブルを参照する場合に、本エラーが発生します。
</p>
<li>contrib/postgres_fdw が SELECT文の FETCH FIRST WITH TIES句をリモートサーバに送出しないようになりました。  (Japin Li) (16)(15)(14)(13)</li>
<p>
リモートサーバはこの構文を実装していないか、ローカルサーバとは異なる解釈をするかもしれないため、あえてリモートサーバでの実行を試みることはないと判断されました。
</p>
<p>
本構文がサポートされたのは PostgreSQL 13.x 以降です。
</p>
<li>OS が提供する <regex.h> ヘッダファイルによる衝突が回避されました。  (Thomas Munro) (16)(15)(14)(13)(12)</li>
<p>
maxOS バージョン 15 以降でのコンパイル失敗が修正されます。
</p>
<li>プラン要素 Memoize のコスト見積での無害なアサート失敗が修正されました。  (David Rowley) (16)(15)(14)</li>
<li>SP-GiST インデックスに対する REINDEX CONCURRENTLY 実行での無害なアサート失敗が修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<li>PL/Perl と Perl 5.40 との非互換性が修正されました。  (Andrew Dunstan) (15)(14)(13)(12)</li>
<p>
この修正は 9.2.x から 11.x のリポジトリでも修正適用されています。
</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 13.15 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/13-15/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Fri, 24 May 2024 02:40:23 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 13]]></category>
		<category><![CDATA[PostgreSQL 13.14]]></category>
		<category><![CDATA[PostgreSQL 13.15]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=14661</guid>

					<description><![CDATA[このリリースは 13.14 からの修正リリース（2024年 5月 9日リリース）です。 13.X からのアップデートではダンプ、リストアは不要です。 しかしながら、13.14 よりも前のバージョンからアップデートする場合 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 13.14 からの修正リリース（2024年 5月 9日リリース）です。<br />
13.X からのアップデートではダンプ、リストアは不要です。</p>
<p>しかしながら、13.14 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/13-14/" rel="noopener">13.14 のリリース情報</a>も参照してください。</p>
<p><span id="more-14661"></span></p>
<h3>PostgreSQL 13.14 から 13.15 への変更点</h3>
<p>16.3、15.7、14.12、13.15、12.19 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>pg_stats_ext と pg_stats_ext_exprs の行の可視性がテーブル所有者だけに制限されました。(CVE-2024-4317)  (Nathan Bossart) (16)(15)(14)</li>
<p>
これらのビューは、アクセスするユーザに読み取り権限の無い列を伴う式の統計情報を隠していませんでした。most_common_vals などのビュー列でデータ露出が生じていました。潜在的な影響は完全には明らかになっていないため、安全性の観点から、これらのビューは関連するテーブルの所有者にしか表示されないものとなりました。
</p>
<p>
この修正では、新たに initdb で作成されたデータベースクラスタにしか修正の影響が及びません。既存のデータベースクラスタに対して適用するには、以下の手順が必要です。
</p>
<pre>
インストール先 share ディレクトリ下の fix-CVE-2024-4317.sql を
スーパーユーザ（下記例では postgres）で各データベースに対して実行する。

  $ psql -U postgres -d 《DB名》 -f "fix-CVE-2024-4317.sql"

このとき template0 データベースも対象にする。
template0 に対して SQLスクリプトを実行するには、
以下のように一時的に接続を許可して行う。

  $ psql -U postgres -c "ALTER DATABASE template0 WITH ALLOW_CONNECTIONS true;"
  $ psql -U postgres -d template0 -f "fix-CVE-2024-4317.sql"
  $ psql -U postgres -c "ALTER DATABASE template0 WITH ALLOW_CONNECTIONS false;"
</pre>
<li>複数の VALUES 行からの INSERT で対象列が配列か複合型を元にしたドメイン型である場合について、修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
このような場合に、予期せぬデータ型の不一致のエラーか、奇妙な INSERT結果（誤った問い合わせ結果）が生じることがありました。
</p>
<pre>
（エラー発生例：1行 INSERT では成功するものが 2行 INSERT で失敗する）
db1=# CREATE typ2 AS (e1 int, e2 text);
db1=# CREATE DOMAIN dom2 AS typ2;
db1=# CREATE TABLE t2 (c1 int, c2 dom2);
db1=# INSERT INTO t2 (c2.e1, c2.e2) VALUES (1, 'A');
db1=# INSERT INTO t2 (c2.e1, c2.e2) VALUES (2, 'B'), (3, 'C');
ERROR:  subfield "e1" is of type integer but expression is of type dom2
</pre>
<li>DO NOTHING を行う MERGE でも対象テーブルに SELECT 権限が必要になりました。  (&Aacute;lvaro Herrera) (16)(15)</li>
<p>
これにより特別なケースでの問題を回避します。「MERGE INTO t3 USING (SELECT 1) ON (true) WHEN MATCHED THEN DO NOTHING」のような形の問い合わせでアサート失敗が生じる場合が報告されました。仕様変更となりますが、実用的な MERGE文の動作に影響は無いと考えられます。
</p>
<li>MERGE による（UPDATE・DELETE アクションによる）自己書き換えタプルの処理が修正されました。  (Dean Rasheed) (16)(15)</li>
<p>
ターゲット行が 2行以上のソース行と結合する場合には、SQL標準に従って、エラーを出すようになりました。これまでの実装では同時更新を伴う場合に本条件を無視することがありました。
</p>
<p>
また、BEFOREトリガや VOLATILE の関数が問い合わせで使われていることで、ターゲット行が同トランザクションのコマンドで既に更新されていた場合に、誤解を招かないエラーメッセージを出すようになりました。
</p>
<pre>
（新たに出るようになったエラーメッセージ）
ERROR:  tuple to be updated or deleted was already modified by an operation triggered by the current command
HINT:  Consider using an AFTER trigger instead of a BEFORE trigger to propagate changes to other rows.
</pre>
<li>テーブルが boolean型の列でパーティショニングされていて、問い合わせが boolean型の「IS NOT」句を持つ場合の、誤った NULLパーティションのプルーニングが修正されました。  (David Rowley) (16)(15)(14)(13)(12)</li>
<p>
「《NULL値》 IS NOT FALSE」のような条件に対して、予期せぬエラーや誤った問い合わせ結果が生じました。
</p>
<pre>
（RANGE、HASHパーティションでは予期せぬエラーが発生）
db1=# CREATE TABLE t5 (b boolean, i int) PARTITION BY RANGE (b, i);
db1=# CREATE TABLE t5p PARTITION OF t5 FOR VALUES FROM (false, 0) TO (false, 1);
db1=# SELECT * FROM t5 WHERE b IS NOT true;
ERROR:  invalid strategy number 0

（LISTパーティションの場合、NULLのパーティションが読み飛ばされる）
db1=# CREATE TABLE t5l (b bool, i int) PARTITION BY LIST (b);
db1=# CREATE TABLE t5lp PARTITION OF t5l FOR VALUES IN (NULL);
db1=# INSERT INTO t5lp VALUES (NULL, 0);
db1=# SELECT * FROM t5l WHERE b IS NOT true;
 b | i
---+---
(0 rows)
</pre>
<li>ALTER FOREIGN TABLE SET SCHEMA の実行で、所有されているシーケンスが新しいスキーマに移動するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
通常のテーブルを新しいスキーマに移動すると、そのテーブルが所有するシーケンスも（インデックスと制約とともに）そのスキーマに移動されます。 しかし、外部テーブルではこのシーケンスの移動が見落とされていました。
</p>
<li>ALTER TABLE ... ADD COLUMN の実行で、所有するテーブルと同じ永続性を持つ IDENTITY/シリアルシーケンスが作成されるようになりました。  (Peter Eisentraut) (16)(15)</li>
<p>
CREATE UNLOGGED TABLE を使用すると、所有されているシーケンスもWAL出力されなくなります。 ALTER TABLE はこの点を考慮していなかったため、追加された IDENTITY列はWAL記録されたシーケンスが含まれることになりますが、これは無意味であると判断されました。
</p>
<li>従属関係を持つ関数またはパブリケーションが存在する場合に発生するALTER TABLE ... ALTER COLUMN TYPE のエラーメッセージが改善されました。  (Tom Lane) (16)(15)(14)</li>
<pre>
db1=# CREATE TABLE t(a int);
db1=# CREATE PUBLICATION p FOR TABLE t WHERE (a > 0);
db1=# ALTER TABLE t ALTER COLUMN a TYPE bigint;
(以前発生していたエラーメッセージ)
ERROR:  unexpected object depending on column: publication of table t in publication p
(改善されたエラーメッセージ)
ERROR:  cannot alter type of a column used by a publication WHERE clause
DETAIL:  publication of table t in publication p depends on column "a"
</pre>
<li>CREATE DATABASE で、他のオプションとの一貫性を保つために、STRATEGY キーワードを大文字と小文字を区別せずに認識するようになりました。  (Tomas Vondra) (16)(15)</li>
<li>Bitmap Heap Scan によってアクセスされたヒープページのEXPLAIN のカウントが修正されました。  (Melanie Plageman) (16)(15)(14)(13)(12)</li>
<p>
以前は、可視タプルを含まないヒープページはカウントされていませんでしたが、Bitmap Index Scan によって返されるすべてのページをカウントする方がより一貫性があると判断されました。
</p>
<li>MERGE のサブプランに対する EXPLAIN 出力が修正されました。  (Dean Rasheed) (16)(15)</li>
<p>
プランツリーの他の部分にある変数を参照する SubPlan のパラメータが適切に表示されないことがありました。EXPLAIN出力中に問い合わせに含まれない ctid列が出現する誤動作が報告されました。
</p>
<li>孤児になった一時テーブルを削除するときに起きるデッドロックを回避するようになりました。  (Mikhail Zhilin) (16)(15)(14)(13)(12)</li>
<p>
一時テーブルを作成するセッションがテーブルを削除せずにクラッシュした場合、自動バキュームが最終的に孤児テーブルを削除しようとします。 ただし、同じ一時名前空間が割り当てられているセッションでも同様に削除しようとします。一時テーブルに依存関係（所有シーケンスなど）がある場合、これら 2つのクリーンアップ試行の間でデッドロックが発生する可能性がありました。
</p>
<p>
このデッドロックは「ERROR:  deadlock detected ...」エラーで検出されます。
</p>
<li>DISABLE_PAGE_SKIPPING オプションを使用した VACUUM での可視性マップ状態の更新が修正されました。  (Heikki Linnakangas) (16)</li>
<p>
見落としにより、この動作モードではすべてのヒープページがダーティになり、過剰な I/O が発生していました。また、誤って設定された可視性マップビットもクリアされませんでした。
</p>
<li>リレーションごとの凍結XID値を検査する際に競合状態を回避するようになりました。  (Noah Misch) (16)(15)(14)(13)(12)</li>
<p>
VACUUM によるリレーションごとの値からのデータベースごとの凍結XID値の計算が、別の VACUUM によるこれらの値の同時更新によって混乱する可能性がありました。
</p>
<li>並列VACUUM処理のバッファ使用量レポートが修正されました。  (Anthonin Bonnefoy) (16)(15)</li>
<p>
並列ワーカによって実行されたバッファアクセスが VERBOSEモードで報告される統計にカウントされませんでした。
</p>
<li>プランナで、同値クラスから生成された結合条件が確実に正しい計画レベルに適用されるようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
PostgreSQL 16 より前のバージョンでは、生成された条件が外部結合の上（後）で評価されるべき時に、外部結合の下で評価される可能性があり、誤った問い合わせ結果が発生する可能性がありました。一部の SELECTアームの結合列に定数出力を持つ UNION ALL ツリーへの結合を検討する場合には、16.x を含む全バージョンに同様の危険性がありました。
</p>
<li>ORDER BY または DISTINCTオプションを使用した集計関数の計画時に発生するエラー「ERROR:  could not find pathkey item to sort」が修正されました。  (David Rowley) (16)</li>
<p>
これは PostgreSQL 16.1 で適用された修正（31番の項目）に似ていますが、本修正では並列プランに対して問題解決します。
</p>
<li>一部のウィンドウ関数への潜在的に間違った最適化が防止されました。  (David Rowley) (16)(15)</li>
<p>
非定数引数を使用した ntile() および count() の Run Condition の最適化を無効にするようになりました。これにより副問合せで発生する可能性のある誤動作が回避されます。誤動作で典型的には「ERROR:  WindowFunc not found in subplan target lists」のようなエラーが生じます。
</p>
<li>移動しないウィンドウフレームで移動集約モードを無駄に使用しないようになりました。  (Vallimaharajan G) (16)(15)(14)(13)(12)</li>
<p>
通常の集約関数がウィンドウ関数として使用されて、ウィンドウフレームの開始が UNBOUNDED PRECEDING として指定されている場合、そのフレームの先頭位置は移動できないため、特別な (そしてより高価な) 移動集計モードを使用する必要はありません。この最適化は当初から意図されていましたが、コーディングエラーのために働いていませんでした。
</p>
<li>GEQO でパーティションごとの結合を計画する時に、解放済データの使用を避けるようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
通常これはクラッシュまたは予期せぬエラーメッセージを引き起こします。
</p>
<li>Memoize で使用中のデータを解放しないようになりました。  (Tender Wang, Andrei Lepikhov) (16)(15)(14)</li>
<p>
運用ビルドでは、解放されたデータは使用前に上書きされない可能性が高いため、このエラーは頻繁には問題を引き起こしませんでした。潜在的にはクラッシュを引き起こす可能性があります。
</p>
<li>「ERROR:  requested statistics kind "X" is not yet built」というメッセージで誤って報告されていた統計の種類コードが修正されました。  (David Rowley) (16)(15)(14)(13)(12)</li>
<p>
エラー発生時に「X」部分が誤って出力されていました。
</p>
<li>「catcache list」オブジェクトを線形検索する代わりにハッシュテーブルを使用するようになりました。  (Tom Lane) (16)</li>
<p>
この変更により、何千ものロールを持つインストレーションにおけるいくつかの操作で報告された性能問題（GRANT ROLE で数十秒かかる等）が解決されます。
</p>
<li>FROM で RECORD を返す関数についてより注意深い実装になりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
このような関数呼び出しの出力列は、列名とデータ型を指定する AS句によって定義する必要があります。実際の関数の出力値がそれと一致しない場合、実行時にエラーになるはずです。
</p>
<p>
しかし、一部のコードパスでは実際の値が通常より早くに検査され、不一致のときに、奇妙なエラーが発行されたり、エラーにならなかったり、アサート失敗が発生したりする可能性がありました。
</p>
<pre>
（修正前バージョンでは結果が返るが、列数不一致でエラーになるのが正しい）
db1=# WITH a(b) AS (VALUES (ROW(1,2,3)))
        SELECT * FROM a, coalesce(b) AS c(d int, e int);
    b    | d | e
---------+---+---
 (1,2,3) | 1 | 2
(1 row)
</pre>
<li>行型を返す SQL言語プロシージャに関する混乱が修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
単一の複合型列を返す SQL言語で実装されたプロシージャでは、アサート失敗またはコアダンプが発生する可能性がありました。
</p>
<pre>
（クラッシュ動作例）
db1=# CREATE TYPE typ AS (a INT, b INT);
db1=# CREATE PROCEDURE p_udt(OUT typ) LANGUAGE SQL AS $$ SELECT (1, 2); $$;
db1=# CALL p_udt(NULL);
server closed the connection unexpectedly
</pre>
<li>内部実装のためのいくつかの再帰関数に保護的なスタック深さ検査が追加されました。  (Egor Chindyaskin) (16)(15)(14)(13)(12)</li>
<li>date_bin() の丸めミスとオーバーフローの危険性が修正されました。  (Moaaz Assali) (16)(15)(14)</li>
<p>
関数 date_bin(stride, source, origin) で、source のタイムスタンプが origin のタイムスタンプより前にあり、それらの差がすでに stride の正確な倍数になっている場合、コードは stride を誤って減算していました。誤った問い合わせ結果が発生します。
</p>
<pre>
（誤動作例）
db1=# select date_bin('30 minutes'::interval, '2024-01-01 15:00:00'::timestamp, '2024-01-01 17:00:00'::timestamp);
      date_bin
---------------------
 2024-01-01 14:30:00
</pre>
<p>
また、整数オーバーフローも検出するようになりました。いずれも誤った問い合わせ結果の原因となります。
</p>
<li>timestamp型の値に interval型の値を足し引きするときに整数オーバーフローを検出するようになりました。  (Joseph Koshakow) (16)(15)(14)(13)(12)</li>
<p>
timestamp型の範囲を越えていて「ERROR:  timestamp out-of-range」を出すべき一部の場合で、ERROR ではなく誤った問い合わせ結果を返していました。
</p>
<li>pg_get_expr() での競合状態を回避するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
引数によって参照されるリレーションが同時に削除された場合、関数は NULL を返すべきところですが、エラーになっていました。
</p>
<li>XIDステータス関数での古いトランザクションID の検出が修正されました。  (Karina Litskevich) (16)(15)(14)(13)(12)</li>
<p>
2^31 を超える過去のトランザクションID が最近のものとして誤認され、pg_xact_status() または txid_status() の誤動作につながる可能性がありました。
</p>
<li>テーブルのフリースペースマップが、テーブルの終端を過ぎたページを返さないようになりました。  (Ronan Dunklau) (16)(15)(14)</li>
<p>
フリースペースマップ（空き領域マップ）は WAL に記録されないため、OS のクラッシュ、レプリカの昇格、PITR リストアなどのエッジケースで、「ERROR: could not read block」が発生する可能性がありました。
</p>
<li>WaitEventSetWait で待機中にエラーが生じた場合の、ファイルディスクリプタのリークが修正されました。  (Etsuro Fujita) (16)(15)(14)(13)(12)</li>
<p>
WaitEventSetWait は PostgreSQL の内部実装関数です。
</p>
<li>外部テーブルへの非同期 Append を伴う問い合わせで、例外スタックが壊れることがあり修正されました。  (Alexander Pyhalov) (16)(15)(14)</li>
<p>
実装内部の状態として、待機条件が設定されていない場合に発生します。実際の障害発生例は報告されていませんが、エラー処理で奇妙な動作やクラッシュが生じる可能性が考えられます。
</p>
<li>インデックスの再作成中にインデックスにアクセスすると、エラーを出すようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
以前は単なるアサーションチェックでしたが、通常の実行時エラーに昇格しました。また、テーブルにアクセスするユーザ定義関数を含む式インデックスを再作成するときに、より的確なエラーメッセージ「ERROR:  cannot access index ... while it is being reindexed」が出ます。
</p>
<pre>
（以前のエラー発生例）
db1=# CREATE TABLE t34(i int PRIMARY KEY);
db1=# CREATE FUNCTION f34(i int) RETURNS int IMMUTABLE LANGUAGE SQL
        AS $$ SELECT i FROM t34 WHERE i = $1 $$;
db1=# CREATE INDEX idx34 ON t34 ( f34(i) );
db1=# INSERT INTO t34 VALUES (1);
db1=# REINDEX INDEX idx34;
ERROR:  could not read block 0 in file "base/26295/26339": read only 0 of 8192 bytes
CONTEXT:  SQL function "f34" during startup
</pre>
<li>name型の列に対する Index Only Scan で、正しい値が返されるようになりました。  (David Rowley) (16)(15)(14)(13)(12)</li>
<p>
以前は、インデックスに物理的に格納されている値ではなく、その値へのポインタが呼び出し元に返されていました。これが valgrind でテストしたときに不適切なメモリアクセスとして検出されました。理論的にはクラッシュが発生する可能性がありますが、実際の発生は報告されません。
</p>
<li>レプリケーションスロットの無効化時に生じる競合状態が修正されました。  (Bertrand Drouvot) (16)</li>
<p>
これにより誤った競合原因を報告する可能性がありました。
</p>
<li>論理レプリケーションでテーブル同期操作が必要かどうかを決定する際の競合状態が修正されました。  (Vignesh C) (16)(15)</li>
<p>
サブスクライバがどのテーブルを同期する必要があるかを特定している間に到着した無効化イベントが忘れられていて、新たに同期が必要なテーブルがタイムリーに処理されない可能性がありました。
</p>
<li>4GB を超える DSM（動的共有メモリ）割り当てによるクラッシュが修正されました。  (Heikki Linnakangas) (16)(15)(14)(13)(12)</li>
<li>新しいサーバーセッションのクライアントソケットを非ブロッキングモードにできない場合は、そのセッションを切断するようになりました。  (Heikki Linnakangas) (16)(15)(14)(13)(12)</li>
<p>
理論的にはブロッキングモードのソケットで操作することも可能でしたが、長い間完全には機能していませんでした。後で誤動作するよりは接続開始時に失敗した方がよい判断されました。
</p>
<li>OpenSSL 3.0.0 以降での不適切なエラー報告が修正されました。  (Heikki Linnakangas, Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
OpenSSL によって、システムより報告されたエラーを PostgreSQL は、読み取り可能なものではなく、数値のエラーコードで報告していました。
</p>
<li>Windows で API関数 getaddrinfo() のエラー報告処理のスレッドセーフ性が修正されました。  (Thomas Munro) (16)</li>
<p>
マルチスレッドの libpq クライアントプログラムは、ネットワークルックアップの失敗後に、誤った、あるいは破損したエラーメッセージを受け取る可能性がありました。
</p>
<li>libpq と ecpglib が、Cライブラリ関数 bindtextdomain() への同時呼び出しを回避するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
GNU gettext の実装では同時呼び出しは問題ないようですが、Windows で利用可能なバージョンではそうではありません。
</p>
<li>ecpg のプリプロセッサがクラッシュする問題が修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
プログラムがプリプロセッサのコマンド行で定義されたマクロを再定義しようとした場合に発生します。
</p>
<li>ecpg が「unspported feature will be passed to server 」という誤った警告を出さないようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<li>ecpg を Infomix互換モードで実行したときに、追加される関数 intoasc() の結果文字列が正しくゼロ終端されるようになりました。  (Oleg Tselebrovskiy) (16)(15)(14)(13)(12)</li>
<li>initdb の -c オプションでは、大文字と小文字を区別せずにパラメータ名を照合するようになりました。  (Tom Lane) (16)</li>
<p>
サーバはパラメータ名の大文字と小文字を区別せずに処理するため、このコードも同様に処理する必要があります。これにより、生成された postgresql.conf ファイルに冗長なエントリが追加されることを回避します。
</p>
<li>psql でクエリがキャンセルされた後にクエリ結果がリークしないようになりました。  (Tom Lane) (16)(15)</li>
<p>
この問題は「\;」で区切られたクエリ文字列内の、最後のクエリでないクエリのキャンセルの場合にのみ発生していました。
</p>
<li>ロールのコメントが存在する場合、 --no-role-passwords の設定に関係なく、ロールのコメントがダンプされるように pg_dumpall が修正されました。  (Daniel Gustafsson, &Aacute;lvaro Herrera) (16)(15)(14)(13)(12)</li>
<li>MacOS 上で、pg_basebackup、pg_checksums、および pg_rewind で .DS_Store という名前のファイルをスキップするようになりました。  (Daniel Gustafsson) (16)(15)</li>
<p>
これにより Finder がそのようなファイルを作成するときの問題が回避されます。
</p>
<li>PL/pgSQL の式に続く単一行コメント (「--」形式のコメント) の解析が修正されました。  (Erik Wienhold, Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
この間違いにより、このようなコメントが PL/pgSQL CASE ステートメントの「WHEN」式の後に続く場合、解析エラーが発生していました。
</p>
<pre>
（エラー発生例）
db1=# CREATE FUNCTION f50(p1 int) RETURNS text LANGUAGE plpgsql AS $$
      BEGIN
        CASE p1
        WHEN 1 -- comment before THEN
          THEN RETURN 'one';
        ELSE RETURN 'other';
        END CASE;
      END; $$;

db1=# SELECT f50(1);
ERROR:  syntax error at end of input
LINE 1: SELECT "__Case__Variable_2__" IN (1 -- comment before THEN)
                                                                   ^
QUERY:  SELECT "__Case__Variable_2__" IN (1 -- comment before THEN)
CONTEXT:  PL/pgSQL function f50(integer) line 3 at CASE
</pre>
<li>contrib/amcheck で、短いヘッダ値と長いヘッダ値による誤った一致の失敗を報告しないようになりました。  (Andrey Borodin, Michael Zhilin) (16)(15)(14)(13)(12)</li>
<p>
ヒープタプルやインデックスタプルの可変長データは、作成時に適用された圧縮パラメータに応じて、短いヘッダか長いヘッダを持つことができます。これらのケースで違いがある場合にエラーを出すのではなく、同等なものとして扱うようになりました。
</p>
<pre>
（エラー例：論理的には同じ 2タプルがあり、ヘッダ長が 1バイトと 4バイトで異なる）
db1=# CREATE TABLE t51 (v text);
db1=# ALTER TABLE t51 ALTER COLUMN v SET STORAGE PLAIN;
db1=# INSERT INTO t51 VALUES ('x');
db1=# COPY t51 TO '/tmp/t51.dat';
db1=# COPY t51 FROM '/tmp/t51.dat';
db1=# CREATE INDEX t51_idx ON t51(v);
db1=# CREATE EXTENSION IF NOT EXISTS amcheck;
db1=# SELECT bt_index_check('t51_idx', true);
ERROR:  heap tuple (0,2) from table "t51" lacks matching index tuple within index "t51_idx"
</pre>
<li>BRIN 出力関数のバグが修正されました。  (Tomas Vondra) (16)(15)(14)</li>
<p>
これらの出力関数は、contrib/pageinspect でインデックスエントリを表示するためにのみ使用されるため、誤りが実際に問題になることはほとんどありません。
</p>
<li>contrib/postgres_fdw で、定数によるソート要求を発行しないようになりました。  (David Rowley) (16)(15)(14)(13)(12)</li>
<p>
これは、定数発行サブクエリと「UNION ALL」が関係する場合に発生する可能性がありました。もちろん、定数による並べ替えは無意味ですが、リモートサーバーによって誤って解釈され、「ERROR:  ORDER BY position N is not in select list」が発生する危険性もありました。
</p>
<li>contrib/postgres_fdw でリモートセッションのタイムゾーンを「UTC」ではなく「GMT」に設定するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
これは実用上は同じ結果になるはずです。しかし、「GMT」はサーバ内のハードウェアに組み込まれているコードによって認識されますが、「UTC」はタイムゾーンデータベースで検索されます。 そのため、リモートサーバのタイムゾーンデータベースにエントリが欠落しているという万が一の事態が発生した場合、古いコードでは失敗する可能性がありました。
</p>
<li>contrib/xml2 において、最近の libxml2 のバージョンで非推奨となったライブラリ関数の使用を避けるようになりました。  (Dmitry Koval) (16)(15)(14)(13)(12)</li>
<li>LLVM 18 との非互換性が修正されました。  (Thomas Munro, Dmitry Dolgov) (16)(15)(14)(13)(12)</li>
<li>「make check」が musl C ライブラリで動作できるようになりました。  (Thomas Munro, Bruce Momjian, Tom Lane) (16)(15)(14)(13)(12)</li>
<li>CREATE RULE コマンドで、既にコマンド内の外側で使用されているテーブルをビューに変換することが禁止されました。  (Tom Lane) (15)(14)(13)(12)</li>
<p>
これにより、クラッシュの可能性が回避されました。
</p>
<pre>
（クラッシュ例: 変換対象の t2 が同コマンド内の外側で参照されている）
db1=# CREATE TABLE t1 (id int, v text);
db1=# CREATE TABLE t2 (id int, v text);
db1=# CREATE FUNCTION convert_tbl2view() RETURNS SETOF t1 LANGUAGE plpgsql AS
      $$ BEGIN EXECUTE
         'CREATE RULE "_RETURN" AS ON SELECT TO t2 DO INSTEAD SELECT * FROM t1';
         RETURN QUERY EXECUTE 'SELECT * FROM t1 LIMIT 0'; END; $$;
db1=# SELECT * FROM t2 UNION ALL SELECT * FROM convert_tbl2view();
server closed the connection unexpectedly
</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 13.14 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/13-14/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Tue, 27 Feb 2024 00:05:58 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 13]]></category>
		<category><![CDATA[PostgreSQL 13.13]]></category>
		<category><![CDATA[PostgreSQL 13.14]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=14421</guid>

					<description><![CDATA[このリリースは 13.13 からの修正リリース（2024年 2月 8日リリース）です。 13.X からのアップデートではダンプ、リストアは不要です。 しかしながら、本バージョンでの GINインデックスの修正については、イ ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 13.13 からの修正リリース（2024年 2月 8日リリース）です。<br />
13.X からのアップデートではダンプ、リストアは不要です。</p>
<p>しかしながら、本バージョンでの GINインデックスの修正については、インデックスが既に破壊されている可能性もあるためアップグレード後にインデックス再作成することを推奨します。<br />
また、13.13 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/13-13/ ">13.13 のリリース情報</a>も参照してください。</p>
<p><span id="more-14421"></span></p>
<h3>PostgreSQL 13.13 から 13.14 への変更点</h3>
<p>16.2、15.6、14.11、13.14、12.18 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>REFRESH MATERIALIZED VIEW CONCURRENTLY 内でのセキュリティ上の制限を厳格化しました。  (Heikki Linnakangas) (16)(15)(14)(13)(12)</li>
<p>
同時リフレッシュのある一段階が弱いセキュリティ制限のもとで実行されていました。マテリアライズドビューの所有者が、何らか説きつけて、スーパーユーザや他の高権限ユーザにそのビューの同時リフレッシュをさせた場合、REFRESH を実行したユーザの権限でコードを実行させることができました。
</p>
<p>
全てのユーザ定義コードはマテビュー所有者として実行されるように修正されました。これが期待される動作でした。
</p>
<p>
この誤りを使った権限奪取は PostgreSQL 16.x では実施できないことが知られていて、おそらく 16.x では実際には脆弱性が無いと見られます。(CVE-2024-0985)
</p>
<li>JIT のインライン化を実行する時のメモリリークが修正されました。  (Andres Freund, Daniel Gustafsson) (16)(15)(14)(13)(12)</li>
<p>
多数の JITコンパイルの後にバックエンドプロセスがメモリ不足状態になることが報告されていました。
</p>
<li>不正なパーティション結合のプランが生成されないように修正されました。  (Richard Guo) (16)(15)(14)(13)(12)</li>
<p>
LATERAL参照を伴うまれな状況で、不正な実行プランが作られる可能性がありました。影響を受ける場合には、誤った問い合わせ結果が返る、「ERROR:  variable not found in subplan target list」などの奇妙なエラーになる、あるいは、エグゼキュータでプロセスがクラッシュする可能性がありました。
</p>
<li>PlaceHolderVar でサブクエリ出力式の不正なラッピングが修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
サブクエリが、外部結合の下にあって、外部結合のスコープ外にあるものを LATERAL参照する出力列を持っているとき、誤った問い合わせ結果が生じる可能性がありました。外部結合により生じるべき出力列の NULL が、異なる値になる可能性がありました。
</p>
<p>
PlaceHolderVar はプランナの実装コードにおいて別のプランノード結果から値が充当される変数を意味します。
</p>
<li>ウィンドウ関数の条件実行（EXPLAIN で「Run Condition:」と出力される動作）の誤動作が修正されました。  (Richard Guo) (16)(15)</li>
<p>
本誤りにより予期せぬエラー「ERROR:  WindowFunc not found in subplan target lists」が生じるおそれがありました。
</p>
<li>Memoize プランについて内側のユニーク性の検出について修正されました。  (Richard Guo) (16)</li>
<p>
この誤りにより「ERROR:  cache entry already complete」が生じるおそれがありました。
</p>
<li>定数畳み込みをするフィールドを選択するときの varnullingrels の計算が修正されました。  (Richard Guo) (16)</li>
<p>
「ERROR:  wrong varnullingrels (b) (expected (b 3)) for Var 2/2」といった予期せぬエラーが発生することがありました。
</p>
<p>
varnullingrels はプランナの実装コードにおける変数ノードの修飾情報の一つです。
</p>
<li>MERGE がパーティションにまたがる更新をするときに、不適切な動作を行わないようになりました。  (Dean Rasheed) (16)(15)</li>
<p>
パーティションテーブルに対して MERGE UPDATE 動作をするときに、パーティションキーを変更するために UPDATE が DELETE と INSERT に置き換えられる場合に「AFTER UPDATE ROW」トリガを発効しないようになりました。RLS 検査などの他の UPDATE 後のアクションも同様に行われなくなります。
</p>
<p>
これらのアクションは一般的には失敗します。このことは通常の UPDATE で実行しない理由であり、MERGE でも実行すべきではありません。
</p>
<li>パーティションにまたがる MERGE の更新で、BEFORE ROW DELETE トリガが動作するようになりました。  (Dean Rasheed) (16)(15)</li>
<p>
このようなトリガが NULL を返すことで更新を妨げようとした場合、MERGE がエラーやアサート失敗を引き起こしていました。
</p>
<p>
「ERROR:  could not open file "base/16384/16393.1" (target block 3081245700): previous segment is only 1 blocks」というエラーが出るケースが報告されました。
</p>
<li>BEFORE ROW UPDATEトリガで PINされていないバッファへのアクセスが防止されました。  (Alexander Lakhin, Tom Lane) (16)(15)(14)</li>
<p>
更新中タプルが別セッションによって更新されて別ページに移動されたばかりの場合、バッファへの PINなしに新しいタプルバージョンからデータを取得しようとするタイミングがありました。これにより原理的には、新タプルの未更新列にガベージデータが表示される可能性がありました。
</p>
<p>
実際に問題が生じる可能性は低いと見られます。
</p>
<li>パラレルハッシュ結合で巨大な共有メモリ領域の要求が回避されました。  (Thomas Munro, Andrei Lepikhov, Alexander Korotkov) (16)(15)(14)(13)(12)</li>
<p>
上限値が大きすぎたために、予想ハッシュテーブルサイズが大きい場合に「ERROR:  invalid DSA memory alloc request size ..」エラーが発生することがありました。
</p>
<li>一時テーブルを拡張しようとしてエラーが発生するときに、ローカルバッファ状態が破損されることがあり、修正されました。  (Tender Wang) (16)</li>
<p>
ディスク不足時にエラーが生じた後、アサート失敗が生じるケースが報告されました。
</p>
<li>複数引数を持つ DISTINCT 指定された集約を評価するときに、誤ったタプルスロットの使用が修正されました。  (David Rowley) (16)</li>
<p>
この誤りにより、エグゼキュータで「ERROR:  attribute 1 of type record has wrong type」などのエラーが生じる可能性がありました。
</p>
<pre>
（エラー発生例）
db1=# SELECT
        string_agg(DISTINCT 'a', ','),
        sum((SELECT sum(1) FROM (VALUES(1)) b(id) WHERE a.id = b.id))
        FROM unnest(array[1]) a(id);
ERROR:  attribute 1 of type record has wrong type
DETAIL:  Table has type text, but query expects integer.

（正しい応答）
 string_agg | sum
------------+-----
 a          |   1
(1 row)
</pre>
<li>外部キーの制約トリガで更新されるタプルが追加の可視性検査に失敗するときに、heap_update() と heap_delete() でアサート失敗にならないように修正されました。  (Alexander Lakhin) (16)(15)(14)(13)(12)</li>
<p>
この誤りはアサートを無効にした実運用むけビルドでは、何ら影響はありません。
</p>
<li>複雑な継承テーブルツリーに対する ALTER TABLE .. ADD COLUMN でエラーになることがあり、修正されました。  (Tender Wang) (16)(15)(14)(13)(12)</li>
<p>
孫テーブルが複数の中間の親テーブルを通して新たな列を継承した場合、「ERROR:  tuple already updated by self」エラーが生じました。
</p>
<li>ALTER TEXT SEARCH CONFIGURATION ... MAPPING で指定するトークン名が重複している場合の問題が修正されました。  (Tender Wang, Michael Paquier) (16)(15)(14)(13)(12)</li>
<p>
これまでは「ERROR:  tuple already updated by self」が発生していました。
</p>
<li>DROP RULE で重複したロール名を指定した場合について修正されました。  (Michael Paquier) (16)</li>
<p>
これまでは「ERROR:  tuple already updated by self」が発生していましたが、これからは重複した指定を無視してエラーを出さないようになります。
</p>
<pre>
（これまでのエラー例）
db1=# CREATE ROLE u;
db1=# DROP ROLE u, u;
ERROR:  tuple already updated by self
</pre>
<li>DROP STATISTICS が関連するテーブルに適切にロックを取得するようになりました。  (Tomas Vondra) (16)(15)(14)(13)(12)</li>
<p>
ロック取得不足のため、DROP STATISTICS を ANALYZE と同時に実行した場合に、「ERROR:  tuple concurrently deleted」が発生していました。
</p>
<li>GENERATED と DEFAULT の式で関数の揮発性検査が修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
これらの場所では、関数のデフォルト引数に VOLATILE 関数が指定されているのを検出できなかったり、使われる具体的なデータ型について実際には IMMUTABLE であるのに多様関数を VOLATILE と判断したりする可能性がありました。
</p>
<p>
これにより GENERATED句を不適切に拒否または受け入れしたり、ALTER TABLE .. ADD COLUMN で定数デフォルト値の最適化を誤って適用したりする可能性がありました。
</p>
<li>フィールドを TOAST から展開するときに、新たなカタログキャッシュエントリが古くなったことを検出するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
カタログタプルの行外フィールドは何であれ、カタログキャッシュに挿入する前に、TOAST展開されます。これはカタログキャッシュエントリを無効化するかもしれないデータベースアクセスと関わりますが、新たなエントリはまだキャッシュに存在していません。その結果、既に古くなったキャッシュエントリが作られて永続化するかもしれないという競合動作になります。これにより（例えば DDL の同時実行で稀に）予期せぬ振る舞いがもたらされました。
</p>
<p>
TOAST展開後にタプルの可視性を再チェックすることで修正されました。
</p>
<li>一部プラットフォームにおけるエッジケースの整数オーバーフロー検知の誤りが修正されました。  (Dean Rasheed) (16)(15)(14)(13)(12)</li>
<p>
「0 - INT64_MIN」の計算はオーバーフローエラーとなるべきで、大部分のプラットフォームではそうなっています。しかしながら、組み込みの整数オーバーフローが無く、128-bit整数も無いプラットフォームの場合、オーバーフローを検知できず、INT64_MIN の値を返していました。
</p>
<li>timestamp型の値に interval型の値を足し引きするときに、ユリウス日のオーバーフローを検出するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
timestamp型の範囲を越えていて「ERROR:  timestamp out-of-range」を出すべき一部の場合で、ERROR ではなく誤った問い合わせ結果を返していました。
</p>
<li>interval_mul() と interval_div() でオーバーフロー検査を更に追加しました。  (Dean Rasheed) (16)(15)(14)(13)(12)</li>
<p>
interval型の値の掛け算と割り算で、「ERROR:  interval out of range」を出すべき一部ケースで、ERROR ではなく誤った問い合わせ結果を返していました。
</p>
<li>内部実装関数 scram_SaltedPassword() が割り込み可能になりました。  (Bowen Shi) (16)</li>
<p>
大きな scram_iterations（イテレーション回数が多い）場合に、本関数は時間を要します。本関数は例えば password_encryption が scram-sha-256 であるときに ALTER ROLE ... PASSWORD '...' でパスワード変更するときに使われます。本修正により本関数実行中に問い合わせのキャンセルが可能になりました。
</p>
<li>設定パラメータ stats_fetch_consistency が変更されたときに、キャッシュされた統計情報が確実に破棄されるようになりました。  (Shinya Kato) (16)(15)</li>
<p>
一部のコードパスで、古い統計情報が返される可能性がありました。本修正は以下のビューの応答に影響があります。
</p>
<pre>
 pg_stat_archiver
 pg_stat_bgwriter
 pg_stat_checkpointer
 pg_stat_io
 pg_stat_slru
 pg_stat_wal
</pre>
<li>pg_file_settingsビューが backend および superuser-backend コンテキストの設定について未適用の値の妥当性を検査するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
これまで、該当の設定パラメータについて無効な値であっても error列に何も出力されませんでした。
</p>
<pre>
(16.x での該当設定パラメータ)
 ignore_system_indexes
 jit_debugging_support
 jit_profiling_support
 log_connections
 log_disconnections
 post_auth_delay
</pre>
<li>新たなパーティションインデックスに既存インデックスを当てはめるときに、照合順序も一致させるようになりました。  (Peter Eisentraut) (16)(15)(14)(13)(12)</li>
<p>
これまではパーティションキーの対応する要素から、異なる照合順序を持つインデックスも受け入れていて、誤動作を引き起こす可能性がありました。
</p>
<li>パーティションインデックスに対する REINDEX INDEX で、子インデックスが同時に削除された場合のエラーを回避するようになりました。  (Fei Changhong) (16)(15)(14)</li>
<p>
予期せぬ「ERROR:  could not open relation with OID」が発生していました。
</p>
<li>GINインデックスの内部ページの不完全な分割をクリーンアップする時の、不十分なロックが修正されました。  (Fei Changhong, Heikki Linnakangas) (16)(15)(14)(13)(12)</li>
<p>
バッファへの（排他ロックではなく）共有ロックでこれを行おうとしていましたが、二つのプロセスが同時にクリーンアップを行おうとするとインデックス破損が生じる可能性がありました。
</p>
<li>GINインデックスの挿入で早すぎるバッファPIN の解放が回避されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
インデックスのルートページの分割が自身の挿入と同時に生じると、「ERROR:  buffer NNNN is not owned by resource owner」になる可能性がありました。
</p>
<li>パーティションテーブルに対する SP-GiSTインデックス のエラーが回避されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
このようなインデックスを使用しようとして、「ERROR:  could not open file "pg_tblspc/0/PG_16_202307071/0/0": No such file or directory」といったエラーが生じる可能性がありました。
</p>
<li>ラージオブジェクトの所有者検査が修正されました。  (Tom Lane) (16)</li>
<p>
所有者権限が必要なラージオブジェクト操作（例えば GRANT や COMMENT）で、所有者ユーザであってもスーパーユーザでない限り、「ERROR:  unrecognized class ID: 2613」といったエラーが出て失敗しました。
</p>
<li>ラージオブジェクトの所有者変更の報告について修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
何もしない ALTER LARGE OBJECT OWNER コマンド（元の所有者を指定するなど）が、誤った class ID を PostAlterHook に渡していました。本フックを使っている拡張に混乱をもたらしていたと考えられます。
</p>
<li>EXPLAIN (BUFFERS) での I/O タイミングデータの報告が修正されました。  (Michael Paquier) (16)(15)</li>
<p>
「shared/local」ラベルの数は実際には共有バッファだけを参照していました。本修正で、このラベルは「shared」に変更されました。
</p>
<li>CREATE DATABASE の耐久性が保証されるようになりました。  (Noah Misch) (16)(15)</li>
<p>
これまで、CREATE DATABASE の実行中や直後に OSクラッシュが生じた場合、リカバリに失敗したり、起動後にそのデータベースへの接続に失敗する可能性がありました。同様のタイミングでベースバックアップを取得した場合にも、そのバックアップを使用する時に似た問題が起きる可能性がありました。症状としては、データベースディレクトリや PG_VERSIONファイル、pg_filenode.mapファイルが欠損するか空になります。
</p>
<li>バックアップからのリカバリ開始時、終了時に「LOG」メッセージをより多く出すようになりました。  (Andres Freund) (16)(15)</li>
<p>
リカバリの問題を診断するのに役立つ追加情報がマスタプロセスのログとして提供されます。具体的には以下のメッセージです。
</p>
<pre>
LOG:  starting backup recovery with redo LSN XX/XXXXXXXX, checkpoint LSN XX/XXXXXXXX, on timeline ID NN
LOG:  restarting backup recovery with redo LSN XX/XXXXXXXX
LOG:  completed backup recovery with redo LSN XX/XXXXXXXX and end LSN XX/XXXXXXXX
</pre>
<li>スタンバイサーバがサブトランザクションでデッドインデックスタプルを不正に処理するのが、防止されました。  (Fei Changhong) (16)(15)(14)(13)(12)</li>
<p>
実装においてサブトランザクションで startedInRecoveryフラグが正しく設定されていませんでした。これはデッドインデックスタプルの処理にのみ影響があります。この誤りにより、サブトランザクション中の問い合わせが返すべき（プライマリではデッドだがスタンバイでは未だ有効な）インデックスエントリを無視してしまう可能性があり、誤った問い合わせ結果が生じます。あるいは、未だプライマリではデッドになっていないインデックスエントリにデッドと早すぎる印付けをしてしまう可能性がありました。後者は深刻な結果になるか明らかではありませんが、想定された動作ではありません。
</p>
<li>walreceiverプロセスのシグナル処理が修正されました。  (Heikki Linnakangas) (16)</li>
<p>
レプリケーション接続確立まで待つ間、walreceiver を SIGTERM に応答しないようにした変更を、旧に戻しました。以前の変更内容では、スタンバイ昇格が妨げられることがありました。
</p>
<li>レコードが WALデコーディングのバッファに収まるかどうかの検査で、整数オーバーフローの危険があり、修正されました。  (Thomas Munro) (16)(15)</li>
<p>
このバグは 64-bitプラットフォーム上で 32-bit ビルドした PostgreSQL を稼働させる場合を除き、顕在化しないと考えられます。
</p>
<li>ロジカルレプリケーションの apply worker と、その tablesync worker、および、ALTER SUBSCRIPTION を試みるセッションプロセスの間のデッドロックが修正されました。  (Shlok Kyal) (16)(15)(14)(13)(12)</li>
<p>
このデッドロックの一端はロック待ちと無関係であるため、デッドロックに陥ると自動では検出できず、（コマンドキャンセルやプロセス停止など）手動で介入しない限り永続的に止まってしまいます。
</p>
<p>
tablesync worker はロジカルレプリケーションのテーブル初期同期を行うものです。apply worker は変更差分の適用を行います。
</p>
<li>pgoutput 論理レプリケーション・プラグインで、列のデフォルト値が正しく転送されることが保証されました。  (Nikhil Benesch) (16)(15)</li>
<p>
新しい列にデフォルトの定数値を持つ ALTER TABLE ... ADD COLUMN ... は、既存のタプルの書き換えをせず、代わりにタプルの読み取りコードが正しいデフォルト値を挿入することを期待していました。
</p>
<p>
その後、そのテーブルでレプリケーションが開始された場合、pgoutput は正しいデフォルト値の代わりに NULL を送信し、サブスクライバで不正なレプリケーションを引き起こしていました。
</p>
<li>列のないテーブルに対する論理レプリケーションの初期同期の失敗が修正されました。  (Vignesh C) (16)(15)</li>
<p>
このケースでは、不適切な形式の COPY コマンドが生成されていました。
</p>
<li>使用する前にサブスクリプションの接続文字列を再検証するようになりました。  (Vignesh C) (16)</li>
<p>
これは、password_required=true のサブスクリプションがスーパーユーザを所有者として接続文字列にパスワードなしで作成されたけれども、その後に所有者が非スーパーユーザに変更されたケースを検出することを目的としています。
</p>
<p>
これまではパスワードファイルや PGPASSWORD環境変数でパスワードが供給されれば、接続文字列にパスワードの無いサブスクリプションを一般ユーザで利用可能でした。
</p>
<li>新しいクライアントが、サーバのパスワードチャレンジに応答せずに切断した場合に、CheckPWChallengeAuth が正しいステータスコードを返すようになりました。  (Liu Lang, Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
CheckPWChallengeAuth は PostgreSQL実装内部の関数です。これまで一部ケースでこの場合をログ出力されるエラーとして扱っていました。これは意図したものではなく、psql のような一般的なクライアントで頻繁にある動作であるため、ログスパムの生成につながっていました。
</p>
<p>
また、この誤りは ClientAuthentication_hook を使用する拡張を混乱させたかもしれません。
</p>
<li>OpenSSL 3.2 との非互換性が修正されました。  (Tristan Partin, Bo Andreson) (16)(15)(14)(13)(12)</li>
<p>
「data」フィールドの使用に代えて BIO「app_data」フィールドを使用するようになりました。以前のバージョンでは問題ありませんでしたが、3.2 ではクラッシュや二重解放のエラーを引き起こしていました。
</p>
<p>
「LOG: could not accept SSL connection: Socket operation on non-socket」というエラーが出てSSL接続に失敗するケースが報告されました。
</p>
<li>OpenSSLがエラー時に errno を設定しないことに、より注意するようになりました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
以前の実装では、errno が設定されていない場合、報告されたエラーの原因は EOF の読み込みだと決めつけていました。 これにより「could not accept SSL connection: Success」のような奇妙なエラー報告が稀に発生していました。
</p>
<li>外部データラッパーの ForeignAsyncRequest関数が失敗した場合の、ファイルディスクリプタのリークが修正されました。  (Heikki Linnakangas) (16)(15)(14)</li>
<p>
外部テーブルから構成されたパーティションテーブルへの問い合わせなどで、非同期実行が使われたときに ERROR を出す場合に、該当している可能性があります。
</p>
<li>CREATE SUBSCRIPTION の接続文字列検証における軽度のメモリリークが修正されました。  (Jeff Davis) (16)</li>
<li>ファイル関連のシステムコールによる ENOMEM エラーを「internal_error」(SQLSTATE: XX000) ではなく、「out_of_memory」(SQLSTATE: 53200) として報告するようになりました。  (Alexander Kuzmenkov) (16)(15)(14)(13)(12)</li>
<li>PL/pgSQL の中で SQL標準形式の本体を持つ CREATE FUNCTION / CREATE PROCEDURE をサポートするようになりました。  (Tom Lane) (16)(15)(14)</li>
<p>
以前は、関数本体にセミコロンが含まれているため、構文エラーとなっていました。
</p>
<pre>
（本マイナーバージョンから実行可能になった PL/pgSQL の例）
db1=# DO LANGUAGE plpgsql $$
      BEGIN
        CREATE FUNCTION f1() RETURNS int
          BEGIN ATOMIC
            SELECT 1;
          END;
        END $$;

（以前は以下のようなエラーになった）
ERROR:  syntax error at end of input
LINE 5:             SELECT 1;
</pre>
<li>libpq によるパイプラインのエラー処理が修正されました。  (&Aacute;lvaro Herrera) (16)(15)(14)</li>
<p>
クエリの問題以外の理由 (接続が失われた場合など) でエラーが返された場合、パイプラインの状態が同期しなくなる可能性があります。これにより、呼び出し側のアプリケーションでビジーループが発生する可能性がありました。
</p>
<li>libpq の PQsendFlushRequest() 関数が、他の「PQsend」関数と同じルールの下でクライアント出力バッファをフラッシュするようになりました。  (Jelte Fennema-Nio) (16)(15)(14)</li>
<p>
パイプラインモードでも、引き続き PQflush() を呼び出す必要がある場合がありますが、この変更により一部の不整合が解消されます。
</p>
<li>libpq が 2つの異なるスレッドで OpenSSL を同時に初期化するときの競合状態を、回避するようになりました。  (Willi Mann, Michael Paquier) (16)(15)(14)(13)(12)</li>
<li>GSSAPI データ送信におけるタイミング依存のエラーが修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
ノンブロッキングモードで GSSAPI 暗号化を使用すると、libpq が「GSSAPI caller failed to retransmit all data needing to be retried」というエラーを出して、サーバへのデータ送出に失敗することがありました。
</p>
<li>postgresql.conf の lc_ で始まる設定パラメータ（例えば lc_messages）のコメントを常に解除するように、initdb が変更されました。  (Kyotaro Horiguchi) (16)</li>
<p>
initdb は V16以前は postgresql.conf の「lc_...」パラメータのコメントを常に解除していて、本マイナーバージョンアップで再び元の動作に戻されました。16.0 の変更により、initdb の --no-locale オプションがlc_messages に意図した効果を及ぼさなくなっていました。
</p>
<li>pg_dump で、拡張のメンバーオブジェクトのRLSポリシーまたはセキュリティラベルをダンプしなくなりました。  (Tom Lane, Jacob Champion) (16)(15)(14)(13)(12)</li>
<p>
以前は、コマンドがこれらのプロパティを設定するためダンプに含まれていましたが、これらのプロパティは拡張機能の内部事項として考慮される必要があるため、全く誤った動作でした。さらに、復元するユーザにはそれらを設定するための十分な権限がない可能性があり、（RLSポリシーをダンプするにはテーブルのロックを取得する必要があるため）ダンプするユーザにもそれらをダンプするための十分な権限がない可能性がありました。
</p>
<li>pg_dump で、元となるテーブルがダンプされていない場合は、拡張統計オブジェクトをダンプしないようになりました。  (Rian McGuire, Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
典型的には「--exclude-table」などの指定で一部テーブルを除外したときに、除外したテーブルの拡張統計オブジェクトも除外するということです。これはインデックスなどの他の依存オブジェクトの動作に準拠します。
</p>
<li>pg_dump のあるコードパスで、メモリ不足を適切に検出するようになりました。  (Daniel Gustafsson) (16)</li>
<li>pgbenchスクリプトが、開いたままのパイプラインで終了することをエラーとして扱うようになりました。  (Anthonin Bonnefoy) (16)(15)(14)</li>
<p>
以前は、\startpipeline コマンドに一致する\endpipeline がない場合、pgbench は奇妙な動作をしていました。これは、pgbench が適切に処理する必要があるケースというよりは、スクリプトのミスのように見えるため、エラーを投げるようになりました。
</p>
<li>BRIN インデックスの bloom演算子クラス で、false_positive_rate に関する過度に厳密なアサートが修正されました。  (Alexander Lakhin) (16)(15)(14)</li>
<p>
false_positive_rate パラメータに最大値を指定したときに、アサート失敗が生じる動作が報告されました。
</p>
<li>contrib/intarray で、INT_MAX に等しい値の要素を持つ配列がgist__int_ops インデックスに挿入された場合のクラッシュが修正されました。  (Alexander Lakhin, Tom Lane) (16)(15)(14)(13)(12)</li>
<li>contrib/pageinspect の hash_bitmap_info() 関数がパーティション化されたハッシュインデックスに適用されるときに、より適切なエラーを報告するようになりました。  (Alexander Lakhin, Michael Paquier) (16)(15)(14)(13)(12)</li>
<p>
「ERROR:  could not open file "....": No such file or directory」といったエラーが生じる動作が報告されました。
</p>
<li>contrib/pgstattuple の pgstathashindex() 関数がパーティション化されたハッシュ インデックスに適用されるときに、より適切なエラーを報告するようになりました。  (Alexander Lakhin) (16)(15)(14)(13)(12)</li>
<p>
「ERROR:  could not open file "....": No such file or directory」といったエラーが生じる動作が報告されました。
</p>
<li>Windows では、pg_ctl および pg_regress でサブプロセスを起動するときに自動実行オプションを抑制するようになりました。  (Kyotaro Horiguchi) (16)(15)(14)(13)(12)</li>
<p>
cmd.exe 経由で子プロセスを起動するときは、/D フラグを渡して、レジストリで指定された自動実行コマンドが実行されないようになりました。これにより予想外の副作用が回避できます。
</p>
<li>ソースコードにおいて、is_valid_ascii() が mb/pg_wchar.h から utils/ascii.h に移動されました。  (Jubilee Young) (16)(15)</li>
<p>
この変更により、pg_wchar.h で「include <simd.h>」を行う必要がなくなりました。一部のサードパーティコードで問題が発生していました。
</p>
<li>libxml2 のバージョン 2.12.0 以降でのコンパイル失敗が修正されました。  (Tom Lane) (16)(15)(14)(13)(12)</li>
<li>Windows での WAL_DEBUG を有効にしたときのコードのコンパイル失敗が修正されました。  (Bharath Rupireddy) (16)(15)(14)(13)</li>
<li>Python のヘッダーファイルからのコンパイラ警告が抑制されるようになりました。  (Peter Eisentraut, Tom Lane) (16)(15)(14)(13)(12)</li>
<p>
PostgreSQL のビルドで選択されるコンパイラオプションは、Python のヘッダファイルの最新バージョンに含まれる構造体に関する警告を引き起こしました。gcc を使用する場合、プラグマを使用してこれらの警告を抑制するようになります。
</p>
<li>LLVM 18 でのコンパイル時に非推奨の警告が出ないようになりました。  (Thomas Munro) (16)(15)(14)(13)(12)</li>
<li>タイムゾーンデータファイルが tzdata release 2024a に更新されました。   (16)(15)(14)(13)(12)</li>
<p>
グリーンランド、カザフスタン、パレスチナの夏時間法の変更、南極観測点のケーシーとボストークの修正、ベトナム、トロント、ミクロン島の歴史的修正が含まれます。
</p>
<li>LWLock のキューから取り出しするときに、待機中のプロセスのリストを検索する必要がなくなりました。  (Andres Freund) (15)(14)(13)(12)</li>
<p>
これにより、待ちリストが長い場合の O(N^2) の動作が修正されました。一部のユースケースでは、これによりスループットが大幅に向上します。
</p>
<li>ロジカルデコーディング中に間違ったスナップショットでシステムカタログを検査することが防止されました。  (Fei Changhong) (15)(14)</li>
<p>
システムカタログを変更するトランザクションの途中でデコーディングが開始されると、デコーダがそれを認識できず、そのトランザクションをカタログ検索の進行中として扱うことができない場合がありました。
</p>
<p>
この修正は、トップレベルのトランザクションにはすでにカタログ変更が含まれているとマークされているけれども、そのサブトランザクションにはマークがついていない場合に対処します。
</p>
<p>
「ERROR: could not map filenode "..." to relation OID」という奇妙なエラーメッセージが出るケースが報告されました。
</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>
