<?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 17.10 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql-17-10/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>Thu, 15 Oct 2026 03:52:19 +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 17.10 &#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 17.11 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/17-11/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Tue, 01 Sep 2026 04:34:01 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 17]]></category>
		<category><![CDATA[PostgreSQL 17.10]]></category>
		<category><![CDATA[PostgreSQL 17.11]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=21094</guid>

					<description><![CDATA[このリリースは 17.10 からの修正リリース（2026年 8月 13日リリース）です。 17.X からのアップデートではダンプ、リストアは不要です。 しかしながら、最初の 3項目のセキュリティ修正は、設定の修正やデータ ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 17.10 からの修正リリース（2026年 8月 13日リリース）です。<br />
17.X からのアップデートではダンプ、リストアは不要です。</p>
<p>しかしながら、最初の 3項目のセキュリティ修正は、設定の修正やデータのクリーンアップが必要となるかもしれません。また、以下に記載の修正項目に該当する GiSTインデックスがある場合には、インデックス再構築が必要となります。</p>
<p>さらに、17.6 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/17-6/" rel="noopener">17.6のリリース情報</a>も参照してください。</p>
<p><span id="more-21094"></span></p>
<h3>PostgreSQL 17.10 から 17.11 への変更点</h3>
<p>18.6, 17.11, 16.15, 15.19, 14.24 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>ロジカルデコーディングの出力プラグインが厳格化されました。新たな設定パラメータoutput_plugin_librariesでの指定が必要となりました。(CVE-2026-6471)  (Jacob Champion) (18)(17)(16)(15)(14)</li>
<p>
これまでは、レプリケーションユーザがロジカルデコーディングむけに任意のライブラリを選ぶことができて（プラグイン名になどフルパス指定も可能）、さまざまな攻撃が可能でした。仕組みを変えずにこれを防げるようにするため、許可された出力プラグインのホワイトリストが導入されました。
</p>
<p>
PostgreSQL本体同梱のpgoutput（ロジカルレプリケーション用）とtest_decoding（単純なテキスト書き出し用）がデフォルトでoutput_plugin_librariesに含まれます。
</p>
<p>
加えて、pg_upgrade --checkで、新クラスタのoutput_plugin_librariesが 旧クラスタ（バージョン 17.x 以降）のレプリケーションスロットで使っているプラグインライブラリを許可していない場合、失敗するようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5d47df21e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2a29b607d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=01992176e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4e1252ee5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=99f205407">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bf3842a64">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7082ce248">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=82fd68801">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4fcccea97">&#167;</a></small></p>
<li>contrib/pgcryptoのPGP暗号化がサポートされない暗号化方式を検出するように、修正されました。(CVE-2026-14663)  (Daniel Gustafsson) (18)(17)(16)(15)(14)</li>
<p>
これまでは、OpenSSLが要求された暗号化方式を（例えば、FIPSモードであるため、あるいは、古いプロバイダがロードされていないために）拒否した場合に、pgcryptoはその失敗を知らせず、プレーンテキストを含む暗号化されないブロックに単にXORを適用していて、その「暗号化」は容易に解読可能でした。これは典型的には非推奨や非FIPSの暗号化アルゴリズム（cipher-algoオプション指定が blowfish/bf, twofish, cast5, 3des などの場合）で発生します。
</p>
<p>
これからはデフォルトでは、OpenSSLでサポートされない方式でのPGP暗号化がエラーになり、これまでの動作により不適切に暗号化されたメッセージの復号もエラーになります。pgp_pub_decrypt()関数、pgp_sym_decrypt()関数などのオプション引数の新たなオプションignore_cipher_failureに1を指定して実行すると、従来通りの振る舞いに戻ります。
</p>
<p>
前述の理由で不適切に暗号化されたメッセージを、'ignore-cipher-failure=1'オプションを指定して復号する場合には、OpenSSLの動作がそのメッセージを作成したときと同じでなければなりません。サポートされない暗号化方式が異なっている場合にはうまくいきません。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ba207f58f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fe32b10fc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b05cfc693">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6ca6023ca">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=472ef7e4a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7e29eb6f4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d97b3f58c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4c5128ca0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7eed42aa8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ba2a63faf">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=953be116c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e2c48c81f">&#167;</a></small></p>
<li>psqlがスクリプト化された「COPY ... FROM STDIN」コマンドに続くインラインデータを、COPY開始時のエラーであっても、読み飛ばすように修正されました。(CVE-2026-6464)  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
これまでは「COPY」コマンドが行の読み込みを始める前に（例えば、対象のテーブルが無い、などで）エラーを起こした場合、psqlはこのことを認識できず、続くインラインデータを読んでSQLとして処理しました。これは良くて誤りであり、悪くするとSQLインジェクションを起こします。
</p>
<p>
これまでも、COPY開始処理が完了してサーバが「PGRES_COPY_IN」を返した後であれば、途中の行読み込みでエラーを起こしても、残りを読み飛ばすように動作していました。
</p>
<p>
本修正が実運用SQLスクリプトに影響を及ぼすことは無いと考えられますが、テスト用スクリプトでは意図的に「COPY ... FROM STDIN」コマンドが失敗するように作られている場合があります。そのような場合には各コマンドの後に「\.」というデータ区切り行を追加する必要があります。さもないと、読み飛ばす行が多すぎる結果になるかもしれません。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d6ab88d37">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=29921259e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=46fa1f6f3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2bdfd5cdc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3fdcfa8f7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5c51ae455">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8cf01e213">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=900894d35">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dca6627de">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=db96e87f9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8cdbabea7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7215c7e96">&#167;</a></small></p>
<li>EXECUTEやFETCHを実行するポータルの出力行型についてクロスチェックを行うようになりました。(CVE-2026-16239)  (Robert Haas) (18)(17)(16)(15)(14)</li>
<p>
EXECUTEとFETCHは2つのポータルを使います。外側の1つはそのステートメント自身のためで、内側の1つはクエリを代わって実行します。これまで、宣言された2つのポータルの行型を異なるものにできて、これを利用してサーバメモリ暴露や任意コード実行を引き起こせました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=64a65ead1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=37b8f3b0e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=60887d348">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7d150b5c9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fc933ce00">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1f49beef2">&#167;</a></small></p>
<li>to_char()で、長いタイムゾーン省略形によるバッファオーバーランが修正されました。(CVE-2026-14669)  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
これは容易にバックエンドプロセスのクラッシュができて、任意コード実行をもたらす攻撃も報告されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3294ab839">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4fafe2380">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=12a620686">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5dbeb69bc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8f64cc83f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5fb3c6389">&#167;</a></small></p>
<li>正規表現によるマッチ、分割の関数で、バッファオーバーランが修正されました。(CVE-2026-14664)  (Masahiko Sawada) (18)(17)(16)(15)(14)</li>
<p>
不正な文字エンコーディングのデータを渡すと、変換バッファの終端を過ぎた位置に書き込みが行なわれる可能性がありました。regexp_match()、regexp_matches()、regexp_split_to_table()、regexp_split_to_array()の各関数の動作が修正されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7df2aa8ef">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b7e5c3f63">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e91dcfcca">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3179253c2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=127a0673f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=890327639">&#167;</a></small></p>
<li>ascii()関数が不正な入力に対して頑健になりました。(CVE-2026-18024)  (Michael Paquier) (18)(17)(16)(15)(14)</li>
<p>
不正な文字エンコーディングのデータが入力されることで、騙されて読むべきでない何バイトかを読んで返す可能性がありました。アサートが有効なビルドでは、アサート失敗も発生します。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=80ce920a5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=08e812c02">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=849da8210">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ac450853d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3b925133b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=42d333a78">&#167;</a></small></p>
<li>pg_restore_attribute_stats()関数でのマルチ範囲型の処理が修正されました。(CVE-2026-16238)  (OpenAI Security Research Team) (18)(17)(16)(15)(14)</li>
<p>
pg_restore_attribute_stats()はプランナ統計情報のダンプ、リストアで使われる関数です。
</p>
<p>
pg_restore_attribute_stats()はマルチ範囲型を元となる範囲型と単純に同様に扱っていました。これは境界ヒストグラムについては有効でしたが、他の種類の統計情報に対しては誤っていました。
</p>
<p>
誤った統計情報のリストアにより、不適切なプラン選択による問合せ実行の遅延や潜在的なプランナ誤動作の可能性が考えられます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b3d9262bb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=08454e8b2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8d428c6e6">&#167;</a></small></p>
<li>scalarineqsel()が、tid型と想定される定数を実際にそうであるか検査するようになりました。(CVE-2026-14668)  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
この想定は組み込みの演算子については成り立ちますが、悪意で作られた演算子には通用せず、クラッシュやサーバメモリ暴露を引き起こします。
</p>
<p>
scalarineqsel()は選択率の見積を返すプランナの内部実装関数の1つです。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0d60ee717">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a2cb5a1cf">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0ebf896f4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=591192e2e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=005ffaa7f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=59205c7e9">&#167;</a></small></p>
<li>tsvector型とtsquery型の実装コードが（個々の要素、全体の長さの両面で）きわめて長い値に対して頑健になりました。(CVE-2026-14662)  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
ドキュメントに記載されていた上限が、全てのコードパスで必ずしも強制されていませんでした。
</p>
<p>
本マイナーバージョンアップで、これまで許容されていたデータについて、以下のようなエラーが出るようになる可能性があり、仕様通りであるものの非互換変更ともいえます。
</p>
<pre>
ERROR:  lexeme is too long for tsvector ...
ERROR:  string is too long for tsvector ...
ERROR:  word is too long to be indexed ...
ERROR:  tsquery is too large
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cb947ca31">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e25135057">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fe0b5bd6d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7c1a8805a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f443d0a0a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7c2ba321d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3b2238fbe">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dddc8a69f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8e87bd473">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=84b6a7a06">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4f8b37b6b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1e3014f37">&#167;</a></small></p>
<li>「FUNC_MAX_ARGS」を超える関数引数を処理する必要がない、と誤って想定していた様々な箇所が修正されました。(CVE-2026-14679)  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
特に集約関数について、実際の引数の数の上限は「FUNC_MAX_ARGS - 1」ですが、パーサ段階では制限しておらず、後の処理で問題を引き起こしました。潜在的にバッファオーバーランの可能性がありました。
</p>
<p>
「FUNC_MAX_ARGS」はビルド時指定の定数でデフォルト100です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=92972e815">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7f0e1aac7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=797e3cc4c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8c67c4cf5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b417744a7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cf44ff5e6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=42d9749b7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2a03f21da">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8a40f4b09">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=32e0d25d4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=eb2fa2704">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c7f462838">&#167;</a></small></p>
<li>internal型を引数や戻り値とする関数のSQLからの呼び出しを拒否するようになりました。(CVE-2026-14680)  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
拒否するための既存の仕組みはありましたが、不十分であったため、明示的な検査が追加されました。
</p>
<p>
また、いくつかの集約関数のcombine処理で入力がNULLである場合に正しくSQLとしてのNULLを返すように修正されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=21a00de43">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=54649de65">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=eb9e55297">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4c0c1b2cd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e926a9aac">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=155dacbc5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=21d8cfb18">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=722695db1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=83d0a083f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7f308dd7c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d6e861e19">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=913fe0c31">&#167;</a></small></p>
<li>ALTER TABLEコマンドで再構築されたとき、拡張統計オブジェクトの所有者が保たれるようになりました。(CVE-2026-6469)  (Masahiko Sawada) (18)(17)(16)(15)(14)</li>
<p>
これまでは拡張統計情報の対象テーブルに、列の型を変えるなどのALTER TABLEコマンドを実行したロールが、拡張統計オブジェクトの所有者になっていましたが、これは不適切な動作と判断されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=93b93f28f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a1fa24127">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=75a03c569">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7c3367ab5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fb6d1ca8d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=70a3b4e18">&#167;</a></small></p>
<li>EXTRACT()関数呼び出しを逆パースするときに、必要であればフィールド名をクォートするようになりました。(CVE-2026-15741)  (Nathan Bossart) (18)(17)(16)(15)(14)</li>
<p>
パーサはEXTRACT()のフィールド名としてどのような文字列リテラルも受け付け、検証は実行時まで先送りされます。関数呼び出しを格納して、解析する場合（例えばpg_dumpのとき）、文字列本体が逐語的に吐き戻されて、SQLインジェクションが可能でした。
</p>
<p>
逆パースはダンプ出力やpsqlでの定義表示で行なわれる処理です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a3832a757">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0ddd9098a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5981fe370">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5e5ea74e3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=44ea6764b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=967acab87">&#167;</a></small></p>
<li>これまで検査ができていなかった個所について、データ型に対する「USAGE」権限を検査するようになりました。(CVE-2026-6470)  (Nathan Bossart) (18)(17)(16)(15)(14)</li>
<p>
「CREATE TYPE AS RANGE」、「ALTER TABLE OF」、および、格納される式を作成するコマンド（式を伴うビューやチェック制約の定義など）で、検査が行なわれていませんでした。これらの欠落により、「USAGE」権限を持たないロールでもデータ型に依存するオブジェクトを作成できて、データ型の所有者が後でデータ型を変更できなくなる可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=efdb26072">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2e91f8548">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fd6d3e7e9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=24855357c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=97e277402">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=323af0a4e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bb1bc525d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=57f59ca1d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=671359605">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7a761fe40">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c062734cd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b6e45b4f8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=424fb7160">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=278053843">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d1c8aa0b0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7ce056b17">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6dbedd48b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1a358b8f2">&#167;</a></small></p>
<li>行単位セキュリティ(RLS)に対して、ロールに依存したキャッシュされたプランを、ロール変更後に無効化するようになりました。(CVE-2026-14666)  (Ilya Staroverov, Shinya Kato, Nathan Bossart) (18)(17)(16)(15)(14)</li>
<p>
ロールのメンバーシップや属性、データベース所有者の変更は、行単位セキュリティポリシーの振る舞いに影響がありますが、これまでは、キャッシュされた古い状態に基づくプランがそのまま使われていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=567286b76">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0b12f56bf">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1974acf23">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f5f2da795">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=17b6083db">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f4174aa84">&#167;</a></small></p>
<li>直接のSSL接続の後のGSSEncRequestメッセージを拒否するようになりました。(CVE-2026-14681)  (Michael Paquier) (18)(17)(16)(15)(14)</li>
<p>
これまでサーバは、TLS暗号化接続が確立した後にもGSSAPI暗号化の要求を受け付けていました。これに成功すると、接続はTLS暗号化(SSL)を使っているけれども、pg_hba.confのルールとしてはGSS接続のように見えました。その結果、pg_hba.confでSSLを無効としていても、それを正しく強制できませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bf1bb7e29">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=203a48209">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=067a64d40">&#167;</a></small></p>
<li>モックのSCRAM認証シークレットがより本物らしくなりました。(CVE-2026-14672)  (Nathan Bossart) (18)(17)(16)(15)(14)</li>
<p>
存在しないロールやSCRAMシークレットを持たないロールに対して、SCRAMログインが試みられた場合、PostgreSQLはモックのシークレットを生成して認証のハンドシェイクをとにかく行ない、攻撃者にそのことが分からないようにします。しかしながら、モックが固定のイテレーションカウントで作られていたため、観測可能な応答の差異がありました。
</p>
<p>
本修正で、モックにもscram_iterations設定パラメータの値を使って、より実際に使われているシークレットに似せるようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4d192fa16">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=822143c4d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dec60e8ad">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fadbe882d">&#167;</a></small></p>
<li>ecpgアプリケーションでの範囲外書き込みが修正されました。サーバから不正なbytea型データを受け取ることで引き起こされます。(CVE-2026-16241)  (Michael Paquier) (18)(17)(16)(15)(14)</li>
<p>
ecpgはbytea型の値は「\x」で始まることを検査せずに想定していました。壊れているか悪意のサーバは2バイトよりも短い文字列を送ってくるかもしれず、そのためにアプリケーションでのメモリ上書きが発生しました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=457b8737a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a14ba29b1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c3c830272">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=39f855e0e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5737110b6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=74c59d062">&#167;</a></small></p>
<li>psqlの「\unrestrict」コマンドの引数でバッククォート展開をしないようになりました。(CVE-2026-18408)  (Nathan Bossart) (18)(17)(16)(15)(14)</li>
<p>
\restrict と \unrestrict は 17.6、16.10、15.14、14.19バージョンでのCVE-2025-8714の修正で導入されましたが、その中で見落としがありました。悪意のサーバからの応答で出力されたダンプにより、リストアを実行するユーザに意図せぬシェルコマンド実行をさせること（シェルコマンドインジェクション）ができました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0119aa30e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=71ca694c7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0bfac9e1f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=33d0c63fb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=df245c374">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2006fca40">&#167;</a></small></p>
<li>pg_dumpにおいてpg_proc.protrftypesのエントリ数がFUNC_MAX_ARGSを超えないという前提が取り除かれました。(CVE-2026-19385)  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
入力引数と出力引数の両方のエントリが存在する可能性があるため、この配列の長さがFUNC_MAX_ARGS（これは入力引数のみに制限するものです）を超えることは十分にあり得ます。仮にそうでは無いとしても、pg_dumpはサーバがpg_dumpと同じFUNC_MAX_ARGSの値でビルドされたと仮定することはできません。オーバーランが発生すると、pg_dump内部でのメモリ破壊を引き起こす可能性がありました。
</p>
<p>
pg_procシステムテーブルに関数定義が格納されて、protrftypes列にTRANSFORM句による変換のためのデータ型の配列が格納されます。FUNC_MAX_ARGSは実装内部の定数で、通常100です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=86cd82bf4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3392cce5c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c2b16f5d4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3299c2ba0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=71ba5705d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=57aa21f69">&#167;</a></small></p>
<li>tieされたPerlの配列やハッシュに対して、PL/Perlが堅牢化されました。(CVE-2026-14670)  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
通常のオブジェクトとは異なる挙動をするtieされたオブジェクトは、メモリの上書きや、破損した結果配列の生成につながる可能性があり、その結果、後で問題が発生する可能性が高い状況でした。
</p>
<p>
tieは、配列やハッシュなどの変数に対して操作用のメソッド群を実装したオブジェクトに結びつける Perl の機能です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8c48cd615">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=87c4b8219">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2d78c34f8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=477a6bdb0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cf4ae7c3b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d7fcfead3">&#167;</a></small></p>
<li>PL/PerlおよびPL/Tclにおけるメモリ割り当て計算時の整数オーバーフローが修正されました。(CVE-2026-14677)  (Heikki Linnakangas) (18)(17)(16)(15)(14)</li>
<p>
これはコードの異なる個所で発生していたCVE-2026-6473と同様の問題で、同じ方法で修正されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a1c1727cb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=028ee716a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b56cc7deb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8bbdc0540">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1eb0d5380">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=aff9dac1c">&#167;</a></small></p>
<li>contrib/amcheckの関数がインデックス式を実行する前にsearch_pathを制限するようになりました。(CVE-2026-14673)  (Noah Misch) (18)(17)(16)(15)(14)</li>
<p>
amcheckはそれらのインデックス式をテーブル所有者の権限で実行するため、呼び出し元がsearch_pathに依存する関数を乗っ取り、テーブル所有者の権限で任意のコードを実行できてしまう恐れがありました。デフォルトでは、amcheck関数の呼び出しはスーパーユーザーにのみ許可されているため、これは脆弱性には当たりません。しかし、もしその権限が他のユーザに付与されていた場合、ドキュメントで示されているよりも大きな危険が生じることになります。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=557cc7186">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0a61fcde0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e41c72aff">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2cc147318">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e43e74756">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=39d792040">&#167;</a></small></p>
<li>contrib/fuzzystrmatchのlevenshtein()およびlevenshtein_less_equal()関数における整数オーバーフローが修正されました。(CVE-2026-15742)  (Nathan Bossart) (18)(17)(16)(15)(14)</li>
<p>
これらの関数に大きなコスト値を渡すと整数オーバーフローが発生し、無意味な結果が生じたり、場合によっては境界外書き込みを引き起こしたりする可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=62c31b490">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e88eb4e76">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c4d51b627">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=61481aa0e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=74916136f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9505175f2">&#167;</a></small></p>
<li>contrib/pg_stat_statementsにおけるバッファオーバーランが修正されました。(CVE-2026-14676)  (Alvaro Herrera) (18)(17)(16)(15)(14)</li>
<p>
クエリの正規化処理において、正規化後の文字列が必要とするサイズが正確に考慮されていませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bb02eba53">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8a31ffc2d">&#167;</a></small></p>
<li>contrib/pg_trgmのGiST picksplit関数におけるデータ型エラーが修正されました。(CVE-2026-14678)  (Heikki Linnakangas) (18)(17)(16)(15)(14)</li>
<p>
このエラーによりバッファの末尾を超えた読み取りを引き起こし、通常は不適切な分割判断の原因となっており、運が悪ければクラッシュに至る可能性もありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=aa7b5815e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=849019a50">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1af08af69">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=24c88cd39">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c7c82a88c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a74aa0854">&#167;</a></small></p>
<li>contrib/refintのプランキャッシュが削除されるようになりました。(CVE-2026-14671)  (Ayush Tiwari) (18)(17)(16)(15)(14)</li>
<p>
このキャッシュの挙動にはいくつかの深刻なバグがありました。特に、check_foreign_key()がカスケードUPDATEクエリに新しいキー値を埋め込んでしまうため、キャッシュされたプランでは、本来使用すべきキー値ではなく、最初に必要とされたキー値が再利用されてしまう問題がありました。最も簡単な解決策は、これを削除することです。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=79a506228">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=66a5146dc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a572dd213">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b7b513d9a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5b72d0279">&#167;</a></small></p>
<li>並列GINインデックスの構築時に、テーブルのpg_class.reltuples値が正しく更新されるようになりました。  (Jan Nidzwetzki, Tomas Vondra) (18)</li>
<p>
並列ワーカーが処理した行数として初期化されていない値を報告する場合があり、その結果、reltuplesがInfinityやNaNといった不正な値になる可能性がありました。このような値が設定されると、その後のautovacuumやautoanalyze操作において、そのテーブルの処理が必要であると判断されなくなる可能性がありました。そうなると、この状態は自動的には解消されません。
</p>
<p>
reltuplesを正しい値にリセットするには、手動でANALYZEコマンドを実行するか、別のインデックスを作成する必要があります。  GINインデックスを持つテーブルがある場合は、reltuplesの値が妥当かどうかを確認することをお勧めします。以下のようなクエリが役立ちます。
</p>
<pre>
SELECT DISTINCT t.oid::regclass, t.reltuples
FROM pg_class t
  JOIN pg_index i ON t.oid = i.indrelid
  JOIN pg_class ic ON i.indexrelid = ic.oid
WHERE t.relhasindex AND ic.relam = 2742;
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5707d7517">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d4420a972">&#167;</a></small></p>
<li>非同期のAppendプランノードを再スキャンする際の、非同期読み取りの不適切な処理が修正されました。  (Alexander Korotkov, Gleb Kashkin, Etsuro Fujita) (18)(17)(16)(15)(14)</li>
<p>
上位のプランノードがAppendの出力をすべて読み取る前にAppendを再スキャンする場合、外部サーバー（例えばpostgres_fdwなど）に対して送信済の未完了リクエストをすべて破棄する必要があります。  サブプランのパラメータが変更された場合や、次回のスキャンでパーティションプルーニングによってサブプランが破棄される場合、この処理が正しく行われていませんでした。  その結果、クエリ結果が不正になったり、無限ループに陥ったり、アサート失敗が発生したりする可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7d74b2644">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4ea497a92">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3704870b2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=894da35b3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7213cbfa0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cec48686a">&#167;</a></small></p>
<li>RANGEパーティションテーブルにおけるパーティションプルーニングの不具合が修正されました。  (David Rowley) (18)(17)(16)(15)(14)</li>
<p>
特定のケースにおいて、本来対象とすべきDEFAULTパーティションがスキップされ、その結果、クエリの結果から行が欠落して、誤った問い合わせ結果となる恐れがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f9282a650">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=02e69be47">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=31f2acde5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9a0cd8e73">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5190732c9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6098f35f4">&#167;</a></small></p>
<li>結果リレーションのプルーニング後に、ModifyTableプランノード内の外部データラッパーの状態を正しく更新するようになりました。  (Ayush Tiwari, Rafia Sabih) (18)</li>
<p>
以前は、実行時のパーティションプルーニングによって、対象のパーティションテーブルの一部のパーティションをスキャンする必要がないと判断された場合、そのテーブルに外部テーブルのパーティションが含まれていると、クラッシュや誤動作が発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1ef917e3a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bba4e095d">&#167;</a></small></p>
<li>「BEFORE UPDATE」トリガーを持つテーブルに対して、「RETURNING OLD」を指定したUPDATE文で発生していた並行更新の処理漏れが修正されました。  (Dean Rasheed) (18)</li>
<p>
対象行が並行して更新された場合、「READ COMMITTED」分離レベルでは、RETURNING句で返される「OLD」値はすべて、更新後の行の値を反映している必要があります。しかし、トリガーが存在する場合、トリガー自体や最終的な出力行では正しい値が参照されていたにもかかわらず、古い値が返されてしまっていました。結果として、誤った問い合わせ結果が生じる可能性があります。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7048e50f8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4908225be">&#167;</a></small></p>
<li>複数の結合キーと多数のNULL値が存在する場合のハッシュ結合の性能問題が修正されました。  (David Rowley) (18)</li>
<p>
NULL値を持つタプルは他のどのタプルとも一致することはないため、ハッシュテーブルに挿入されるべきではありません。  これまでのコードでは、最後の結合列以外の列にNULL値が含まれる場合にこの処理が適切に行われていなかったため、NULL値を含む入力が多数あるとハッシュテーブルが著しく肥大化していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a71a348ed">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f70acc8a2">&#167;</a></small></p>
<li>RETURNING句の式における括弧で囲まれた「OLD」や「NEW」の解析処理が修正されました。  (Marko Grujic) (18)</li>
<p>
「(old).colname」や「(old).*」といった式が誤って処理され、実質的に「NEW」への参照に変換されていました。結果として、誤った問い合わせ結果が生じる可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9108fed3e">&#167;</a></small></p>
<li>value IN (array)式に対するプランナのNULL許容性および厳密性チェックが修正されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)</li>
<p>
これらのチェックは、配列オペランドが空でないことが既知である場合にのみ成功すべきですが、その点が考慮されておらず、本来適用されるべきではない最適化が適用されてしまう問題がありました。これにより、実際の配列が空であった場合、誤った問い合わせ結果が生じる可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9740c68ff">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=277122036">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=26d6b7dc9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6fcee189b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=53470ffba">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=13b627a3e">&#167;</a></small></p>
<li>不適切な結合削除のロジックが修正されました。  (Matheus Alcantara, Richard Guo) (18)(17)(16)</li>
<p>
一部の特殊なケースにおいて、外部結合のNULL許容側由来の定数出力値が、本来NULLに置換されるべき場面でNULLに置換されない問題が発生し、誤った問い合わせ結果が生じる可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8bc479627">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=21f5e659e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cdcec567d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3e1fe25e6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=72457f1df">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9e40d07e1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b308eb366">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d610d8e8b">&#167;</a></small></p>
<li>結合の削除処理において、PlaceHolderVarsのクリーンアップがより徹底されるようになりました。  (Richard Guo, Arne Roland) (18)</li>
<p>
この修正により、アサート失敗や誤った実行計画の生成（とそれに伴う誤った問い合わせ結果や予期せぬエラー）を招く可能性のあった様々なエッジケースが解消されます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e02526795">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=aae47813a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=18105e6db">&#167;</a></small></p>
<li>コンテナデータ型（配列、複合型、範囲型）の等価比較におけるハッシュ可能性に関する漏れていたチェックが追加されました。  (Andrei Lepikhov, Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
プランナは、ハッシュベースの実行計画を採用する前に、コンテナの構成要素の型のハッシュ化可能かどうかを検証する必要がありました。一部の箇所でこの手順が漏れていたため、実行時に「ERROR:  could not identify a hash function for type ...」という予期せぬエラーが発生していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=11aed8d19">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=19152e3c2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cf2bfe073">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=caebac5f1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=64778fac7">&#167;</a></small></p>
<li>プランナが、異なる等価性ルールを持つグループ化ステップより下位へ、WHERE句をプッシュダウンすることを避けるようになりました。  (Richard Guo) (18)</li>
<p>
非決定的照合順序でグループ化される列に対するテストは、その同じ照合順序を使用した比較である場合にのみ、安全にプッシュダウンできます。そうでない場合、グループ化によって統合されるはずだった行がフィルタリングされて、誤った問い合わせ結果が生じる可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=98d5d7ee6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fe5d62951">&#167;</a></small></p>
<li>「EXCLUDE」句を指定している、または「ORDER BY」を指定していない、COUNTウィンドウ関数の誤った最適化が修正されました。  (Chengpeng Yan, David Rowley) (18)(17)(16)(15)</li>
<p>
これまで、このウィンドウ関数は該当しない場合でも単調増加するものとして扱われていました。そのため、誤った問い合わせ結果が生じる可能性がありました。
</p>
<pre>
（報告された誤動作例）
db1=# CREATE TABLE t41 (id int PRIMARY KEY, k int NOT NULL, v int);
db1=# INSERT INTO t41(id, k, v) VALUES
        (1, 1, 1), (2, 1, NULL), (3, 1, 1), (4, 2, 1);

db1=# SELECT id, count(v) OVER (
        ORDER BY k RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
        EXCLUDE CURRENT ROW) AS c FROM t41;
 id | c
----+---
  1 | 1
  2 | 2
  3 | 1
  4 | 2
(4 rows)

db1=# SELECT * FROM (
        SELECT id, count(v) OVER (
          ORDER BY k RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
          EXCLUDE CURRENT ROW) AS c FROM t41) s WHERE c &lt; 2;
 id | c
----+---
  1 | 1
(1 row)
→ 正しくは id=3 の行も出力されないといけない
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fcd58c6d9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cf184ec77">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=be63b285e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a85732162">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=842e34efa">&#167;</a></small></p>
<li>プランナが"char"型の列の統計情報を参照する際に、予期せぬエラー「ERROR:  cache lookup failed for collation 0」が発生する障害が修正されました。  (Feng Wu) (18)</li>
<p>
"char"型は、一般的に使われるchar(n)型とは別の、主として内部的なシステムカタログで使用されるものです。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5fd1c3f28">&#167;</a></small></p>
<li>複数階層のパーティションが存在する場合でも、ALTER TABLEのALTER COLUMN ... DROP EXPRESSIONが正常に動作するよう修正されました。  (Alberto Piai) (18)(17)(16)(15)(14)</li>
<p>
ALTER TABLE ... ALTER COLUMN ... DROP EXPRESSIONは、格納生成列を基本列に変換する構文です。複数階層の子パーティション／子テーブルを持つパーティションテーブルや継承ツリーの親テーブルに対して実行すると、「ERROR:  ALTER TABLE / DROP EXPRESSION must be applied to child tables too」というエラーが発生していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ce6e434ce">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c374f2807">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=18006c1bd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=34785a0d5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=785289de0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cad17745e">&#167;</a></small></p>
<li>排他制約であるインデックスのパーティションをアタッチする処理の不具合が修正されました。  (Japin Li) (18)(17)</li>
<p>
この誤りにより、排他制約を持つパーティションテーブルのダンプ/リストアが正常に動作しなくなっていました。
</p>
<p>
リストア時に以下のようなエラーが発生します。
</p>
<pre>
ERROR:  cannot attach index "..." as a partition of index "..."
DETAIL:  The index definitions do not match.
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2b2c2492c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=19e3aa704">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1d6c654c8">&#167;</a></small></p>
<li>ALTER CONSTRAINTを使用して、パーティションテーブルのNOT NULL制約にNO INHERITを設定することができないように修正されました。  (Andreas Karlsson) (18)</li>
<p>
本来、パーティションテーブルのNOT NULL制約は、すべてのパーティションに継承される仕様であるため、NO INHERITを指定することはできません。これまでは、この仕様は制約を新規作成する際には正しく適用されていましたが、「ALTER TABLE ... ALTER CONSTRAINT」では適用されておらず、NO NULL制約の有無がパーティションごとに異なるようにできました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=41247cdf6">&#167;</a></small></p>
<li>ルールの名前を「_RETURN」に変更できないように修正されました。  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
「_RETURN」という名前は、ビューの「ON SELECT」ルール用に予約されています。これまでは「ON SELECT」以外のルールをALTER RULEで「_RETURN」に名前変更できてしまい、その後の処理で問題を引き起こしていました。
</p>
<p>
具体的には、ダンプ/リストアで「ERROR:  non-view rule for "..." must not be named "_RETURN"」というエラーを起こすことが報告されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=80c7f5467">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a7f7958ab">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e99fb3262">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a69503fb1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=eada45dd8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1b17a6e3c">&#167;</a></small></p>
<li>DROP OWNED BYにおいて、ロールメンバーシップへのロックの解放漏れが修正されました。  (Jeff Davis) (18)(17)(16)</li>
<p>
この不具合により、トランザクションが終了するまで、ロールメンバーシップ（pg_auth_membersシステムテーブルの対応するエントリであらわされる暗黙的なオブジェクト）へのロックが保持され続けていました。その結果、並行するDDL実行で警告メッセージが出ることがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9eccdae22">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a0daa0b41">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=25e54cec7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e61d44fde">&#167;</a></small></p>
<li>EXPLAINがSQL/JSONの集約関数をデパースするときに予期せぬエラーを出すことがあり、修正されました。  (Richard Guo) (18)(17)(16)</li>
<p>
実行プランの構造によっては、「ERROR:  invalid JsonConstructorExpr underlying node type」というエラーが発生していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=eaa561fb6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=45364e496">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dcda1f07d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=485527190">&#167;</a></small></p>
<li>遅延一意性制約のインデックスに対してREINDEX CONCURRENTLYを使用した場合の不具合が修正されました。  (Nitin Motiani) (18)(17)(16)(15)(14)</li>
<p>
REINDEX CONCURRENTLYの実行中に一時的に作成されるインデックスのコピーが、誤って即時一意性制約として扱われていました。そのため、実際には制約違反ではない場合でも、制約違反が発生したと誤って報告することがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9f6fb1191">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e4527519b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=28269fed6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ac222bea5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5b3712e31">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=55adef7ab">&#167;</a></small></p>
<li>非決定論的照合順序でバックスラッシュ（\）を使用したLIKE句のマッチングの不具合が修正されました。  (Nitin Motiani, Tom Lane) (18)</li>
<p>
非決定論的照合順序において、LIKEがエスケープされたバックスラッシュ（\\）を誤って処理し、実質的にバックスラッシュが存在しないものとして扱っていました。
</p>
<p>
また、通常の文字の前にバックスラッシュが付いている場合も誤った処理をしていました。この場合、バックスラッシュは実質的に無視されるべきですが、実際には後続の通常の文字を完全一致として扱ってしまい、非決定論的照合順序にマッチするかを判断していませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=99775b388">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a99bd8d58">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=54d5947ef">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=51652c42d">&#167;</a></small></p>
<li>LIKE句や正規表現の完全一致パターンのインデックススキャン最適化の不具合が修正されました。  (Jelte Fennema-Nio) (18)</li>
<p>
非決定論的な照合順序におけるLIKEのリファクタリングによって、LIKE句や正規表現の完全一致パターンを、等価比較のインデックス条件に変換する最適化が誤って壊れていました。これはインデックスの照合順序と式の照合順序が一致しない場合に発生していました。この影響で、psql の「\d tablename」コマンドが大幅に遅くなっていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=67cf73ddb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d0bb49e61">&#167;</a></small></p>
<li>to_date() におけるローカライズされた月名、曜日名のマッチング処理が修正されました。  (Heikki Linnakangas) (18)(17)(16)(15)(14)</li>
<p>
大文字・小文字の変換によって文字列のバイト長が変化する場合に、マッチング処理が誤動作していました。月名、曜日名が認識されずに予期せぬエラーが発生する可能性が考えられます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=55ea76426">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=011384ba4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8acfaa12a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b594efe52">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0de744cd5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=49a712f32">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5f003855e">&#167;</a></small></p>
<li>ギリシャ文字の語末形のシグマに対する大文字小文字の変換のルールが修正されました。  (Jeff Davis) (18)</li>
<p>
文字列の直前が大文字小文字を区別しない文字だけで構成されている場合、そのシグマを語末形のシグマとはみなさないようにしました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=28d498e28">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=66ec24276">&#167;</a></small></p>
<li>ハングルU+11A7（TBASE）のNFC再合成における誤りが修正されました。  (Diego Frias, Michael Paquier) (18)(17)(16)(15)(14)</li>
<p>
この文字は有効なT音節として扱われていましたが、実際にはT音節ではないため、正規化処理中にこの文字が消えてしまっていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=273fe9485">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0c9cbbfb5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=82116023e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c391375ba">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8bb935d61">&#167;</a></small></p>
<li>大文字小文字を区別しない類義語の辞書において、出力する語彙素が切り捨てられる不具合が修正されました。  (Jeff Davis) (18)(17)(16)(15)(14)</li>
<p>
小文字への変換によって語彙素のバイト長が増加した場合、出力時に元のバイト長に誤って切り捨てられていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=89e648498">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3805641cb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b32df590c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a7e0e42a2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1e0458172">&#167;</a></small></p>
<li>大文字小文字変換処理において、途中で途切れたUTF-8文字への対処が修正されました。  (Jeff Davis) (18)(17)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=05da336dd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9021c8f3c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5e78ebca5">&#167;</a></small></p>
<li>hash_record_extended()のバグが修正されました。  (Man Zeng) (18)(17)(16)(15)(14)</li>
<p>
FunctionCallInvoke()に渡される2番目のisnull引数が初期化されていませんでした。既存の組み込み拡張ハッシュサポート関数では、この値を参照しないため問題はありません。しかし、拡張機能が提供するハッシュ関数が「PG_ARGISNULL(1)」を調べる場合、その影響を受ける可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b3f13c032">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=203e238bb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8b5580a05">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=259b627d5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=74d3482f4">&#167;</a></small></p>
<li>公開可能なテーブルが並行して削除された場合に、pg_get_publication_tables()が失敗する不具合が修正されました。  (Bharath Rupireddy) (18)(17)(16)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=28c995948">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=73d63d1c1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dcbc96685">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6c760f6b6">&#167;</a></small></p>
<li>VARIADIC NULL を指定した場合に、satisfies_hash_partition() がクラッシュする不具合が修正されました。  (Robert Haas) (18)(17)(16)(15)(14)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2ddc45662">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0c06ebf12">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=52af6fef4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6de480156">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d39b9eed0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0115650de">&#167;</a></small></p>
<li>tsvector_filter() および関連する関数で、不正な重みに関するエラーを、より明確かつ一貫した形で報告するよう修正されました。  (Ewan Young) (18)(17)(16)(15)(14)</li>
<p>
具体的には、表示可能なASCII文字ではない重み文字については、charout()と同様に8進数形式（"\nnn"）で報告します。これにより、無効なエンコーディングを含むエラーメッセージが生成されるのを防ぎます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c5194139c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0626fbfeb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ed5ca5828">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b3a86eb6d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=262cc4df2">&#167;</a></small></p>
<li>uundv7()関数で範囲外のタイムスタンプとなるシフト値を拒絶するようになりました。  (Baji Shaik) (18)</li>
<p>
v7 UUIDで表現可能な範囲を超えたタイムスタンプになるシフト値は「ERROR:  timestamp out of range for UUID version 7」というエラーを出すようになります。有効なタイムスタンプ範囲は、1970-01-01 00:00から10889年くらいまでです。これまでは壊れたUUID値が作られていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2a933deaa">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c31b0fca0">&#167;</a></small></p>
<li>xpath()関数でnamestapeノードの処理が修正されました。  (Michael Paquier) (18)(17)(16)(15)(14)</li>
<p>
予期せぬ「ERROR:  could not copy node」エラーが出ていたものが修正されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4c777d6dd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6c08cbb7a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=174076601">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1d8c72b2e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=41876c8d7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0d145be2c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=940916549">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fac26fd41">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9618e790c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a17f39aa2">&#167;</a></small></p>
<li>jsonpathの「.decimal」メソッドが、精度やスケールの指定が正しくない場合でもERRORを出さないように、修正されました。  (Ewan Young) (18)(17)</li>
<p>
サイレントモード（json_path_*関数のsilent引数がtrue）では、エラーを抑止すべきですが、そのようになっていませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5bbc9b300">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=84001a04d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ab35b8d25">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=90789900b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c768637d6">&#167;</a></small></p>
<li>「IS JSON」や「JSON()」等の構文が、text型へのキャストを持たない文字列型の引数を与えられたときの、NULLポインタによるクラッシュが修正されました。  (Ayush Tiwari) (18)(17)(16)</li>
<p>
PostgreSQL本体コードには該当するデータ型はありませんが、一部の拡張のデータ型で問題を引き起こす可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=35d9a6263">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d0acd2535">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=60abb3c73">&#167;</a></small></p>
<li>「SQL/JSON」の「ON EMPTY / ON ERROR DEFAULT」の値に正しい型修飾が確実に適用されるようになりました。  (Ewan Young) (18)(17)</li>
<p>
例えば、対象numeric型列の宣言された精度とスケールがデフォルト値に適用されませんでした。
</p>
<pre>
（誤動作例）
db1=# SELECT JSON_VALUE(jsonb '{"b":"1234.5"}', '$.a' 
        RETURNING numeric(4,1) DEFAULT 99999.9 ON EMPTY);
 json_value
------------
    99999.9
(1 row)

（以下エラーが出るのが正しい動作）
ERROR:  numeric field overflow
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d30bfcbdd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=441e4c8d6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=71cd10cd2">&#167;</a></small></p>
<li>money型の最小値（64bit整数最小値）を-1で割ったときの、マシン依存の振る舞いが回避されました。  (Andrey Rachitskiy) (18)(17)(16)(15)(14)</li>
<p>
x86_64アーキテクチャでエラーになるものが、aarch64アーキテクチャではエラーになりませんでした。オーバーフローを起こした場合には必ず「ERROR:  money out of range」が出るようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7746f7492">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6298a41b4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1416f304d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=86f42357c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d782c97e1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fec40878c">&#167;</a></small></p>
<li>全文検索の辞書に対するキャッシュエントリの作成途中でメモリ不足が生じた後にクラッシュする障害が修正されました。  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=df8407d7d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=81b1e7916">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=634a8dcb8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=83336e3ed">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=025228104">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dda622edc">&#167;</a></small></p>
<li>誤ったispell/hunspell辞書ファイルに対する処理でメモリ安全性に問題があり、修正されました。  (Andrey Rachitskiy) (18)(17)(16)(15)(14)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3fe4062cc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4689ea9ce">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5fdea3aa3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=444038bb7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0fb88979b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cfc720ef4">&#167;</a></small></p>
<li>他セッションの一時テーブルへのアクセスが防止されました。  (Jim Jones, Daniil Davydov, Alexander Korotkov) (18)(17)(16)</li>
<p>
基本的にそのようなアクセスは禁止されていますが、一部のコードパスで防止しきれておらず、干渉されたセッションで誤った問合せ結果が生じるおそれがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1b0dd0815">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4dfae59a1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8021cdceb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3aaefe892">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4e49f68b7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cc3fe7e2a">&#167;</a></small></p>
<li>一時テーブルにアクセスするときの「ERROR: no empty local buffer available」エラーが防止されました。  (Melanie Plageman) (18)</li>
<p>
本修正でストリーミング読み取りの仕組みが使用可能なローカルバッファの数が制限されました。これまでは、effective_io_concurrency設定が大きな値の場合に単一のストリームで全バッファを利用可能であったため、本エラーが発生しました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ed8050370">&#167;</a></small></p>
<li>autovacuumがデータベースを処理する順番が修正されました。  (Rustam Khamidullin) (18)(17)</li>
<p>
最高スコアから最低スコアに向かう順で処理されるべきところで、意図せず逆順になっていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b3331578b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4cc49cb70">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=288d4e83f">&#167;</a></small></p>
<li>VACUUMのXID周回フェールセーフモードで、共有バッファプールを全使用するように動作が復旧されました。  (Melanie Plageman) (18)</li>
<p>
通常のVACUUMは、他の処理に大きな影響を与えないように、共有バッファを少しだけ使うように制限されています。しかしながら、フェールセーフモードではできるだけ早くトランザクションIDを回収する必要があるので、この制限は放棄されることになっていました。この振る舞いがv18のリファクタリングで壊れていて、復旧されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fd90c3221">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=585181e07">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=55d01a10f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7c25cdb1e">&#167;</a></small></p>
<li>パラレルVACUUMワーカーの処理でのメモリリークが修正されました。  (Baji Shaik) (18)(17)</li>
<p>
パラレルワーカーからの報告過程で報告ごとに1kB程度のリークがあり、これはワーカープロセスが生きている間は蓄積されていきました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4154a1482">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8ad414831">&#167;</a></small></p>
<li>問合せのキャンセルとVACUUM遅延が、GINインデックスのポスティングツリーのクリーンアップ中であっても、すぐに行なわれるようになりました。  (Paul Kim, Alexander Korotkov) (18)(17)(16)(15)(14)</li>
<p>
よくある値に対するポスティングツリーは大きくなることがあり、ここに割り込みの検査が欠けていたため、処理が長く継続してしまいました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=70dad584e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7becb647d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ba5e46329">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=006ac761e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7123abab7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=15fd7a3e2">&#167;</a></small></p>
<li>GiSTおよびSP-GiSTのインデックスに対するIndex Only Scanで、インデックスタプルのデコーディングを誤る可能性があり、修正されました。  (Peter Geoghegan) (18)(17)(16)(15)(14)</li>
<p>
この障害で壊れたデータが出力されて、誤った問い合わせ結果や予期せぬエラーが発生する可能性がありました。本体コードで影響があるのは、GiSTの演算子クラスrange_opsのみで、その範囲列が最初のインデックス列でない場合にのみ、誤動作が発生します。
</p>
<pre>
（誤動作例）
db1=# CREATE TABLE t75 (a inet, r numrange);
db1=# INSERT INTO t75 VALUES 
      ('::1', numrange(repeat('1', 100)::numeric, repeat('2', 200)::numeric)));
db1=# CREATE INDEX ON t75 USING gist (a inet_ops, r range_ops);
db1=# VACUUM ANALYZE t75;
db1=# SET enable_seqscan TO off;
db1=# SELECT lower(r) = repeat('1', 100)::numeric,
             upper(r) = repeat('2', 200)::numeric FROM t75;
ERROR:  type with OID 860 does not exist
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1d4c81ad6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=959b7fa2c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=355faed5a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e58192546">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=126141425">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e4ad22eb0">&#167;</a></small></p>
<li>バルク拡張されたテーブルの新たな最終ブロックがフリースペースマップに即座に追加されるようになりました。  (Jingtang Zhang) (18)(17)(16)</li>
<p>
off-by-one（1つ足りない）誤りで、複数ブロックが追加されたときの最後のブロックがフリースペースマップに登録されませんでした。VACUUMによってやがては正しく登録されますが、それまでの間、最終ブロックが使われませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7a103928a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=eabc9a9dd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=768ae083e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0fd5595aa">&#167;</a></small></p>
<li>トランザクションのアボート時のリソース解放処理で、メモリの二重解放（クラッシュをひきおこします）、または、エラーの再帰的な無限ループが起きる可能性があり、修正されました。  (Tom Lane) (18)(17)</li>
<p>
巨大な入力値を伴うSQLがエラーになって、トランザクションアボートが行なわれたケースで問題が報告されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ac6a58a70">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=011eedcdc">&#167;</a></small></p>
<li>PostgreSQLの処理内でディレクトリを作成するとき、同じディレクトリの同時作成を許容するようになりました。  (Andrew Dunstan, Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
他プロセスが同じディレクトリを作っているのであれば、ディレクトリ作成に成功した扱いとすることで、これまで同時実行で発生する可能性のあった「ERROR:  could not create directory "...": File exists」といったエラーを回避できます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=aa80c34c8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f0a831ef3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9951e3d38">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4647ac142">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4b3bc6b71">&#167;</a></small></p>
<li>JITコンパイルされたタプルデフォームを行うコードが、仮想生成列を正しく考慮するように修正されました。  (David Rowley) (18)</li>
<p>
NOT NULL制約のある仮想生成列を含むテーブルへの問合せで、誤った問い合わせ結果が生じる例が報告されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e9692de1d">&#167;</a></small></p>
<li>依存されている全てのオブジェクトに共有ロックを取得することにより、宙に浮いたオブジェクト依存関係の生成が防止されました。  (Bertrand Drouvot) (18)(17)(16)(15)(14)</li>
<p>
共有ロックは依存されているオブジェクトの削除と衝突しますので、これまであった競合状態を排除することができます。
</p>
<p>
例えば、これまでは、空スキーマの削除とスキーマ内へのオブジェクト作成の同時実行が両方成功して、無効なオブジェクト定義が残ることがありましたが、これからはどちらかのトランザクションが失敗します。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c8cd3d697">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3a9909eda">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d9bc0d96c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5fa137727">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5100bdbd3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f9d5a52da">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c1588f92a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d44cd4674">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ef3d7b15e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=36b6ed260">&#167;</a></small></p>
<li>SERIALIZABLE分離モードに対する衝突の検出での競合状態が修正されました。  (Peter Geoghegan) (18)(17)(16)(15)(14)</li>
<p>
初期の空のbtreeインデックスを検査するときに衝突が見過ごされる可能性があり、競合しているトランザクションのコミットを許してしまっていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2aa3c6d1f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d560e730e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8434c9385">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e321faaae">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5d18105ca">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2fc3e1b44">&#167;</a></small></p>
<li>バリアイベントの処理で競合状態が修正されました。  (Masahiko Sawada) (18)(17)(16)(15)</li>
<p>
この誤りにより、プロセスがハングアップする可能性がありました。典型的には、その際に以下ログメッセージが出力されます。待機イベントとしてはIPC型のProcSignalBarrierの待機となります。
</p>
<pre>
LOG:  still waiting for backend with PID %d to accept ProcSignalBarrier
</pre>
<p>
近年追加されたオンラインWALレベル変更などの機能によって、この問題がより目立つようになっています。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1a9b1cc18">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a651b8a89">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cdb9b2830">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=159324a73">&#167;</a></small></p>
<li>同じロックグループに属するプロセス集合が同時に終了したときの競合状態が修正されました。  (Vlad Lesin) (18)(17)(16)(15)(14)</li>
<p>
この誤りは「PANIC:  latch already owned by PID ..」によるサービスのPANIC終了を引き起こす可能性があります。PostgreSQL本体の通常のパラレル問合せでは、リーダープロセスがワーカープロセスの終了を待たずに終了することが無いため、この問題は起きませんが、何らかの拡張で該当する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ae08eb168">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d489c4439">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=65d04df60">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d5cc6df60">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8007d1185">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=12c9b8b42">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e14b4ea4a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4e8edf53f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e786fb5aa">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=db4d12fc9">&#167;</a></small></p>
<li>テーブルのビジビリティマップ(VM)でビットをクリアする操作のWAL出力が修正されました。  (Melanie Plageman, Andres Freund) (18)(17)</li>
<p>
このようなVM変更がWALサマライズ処理で見落とされていて、誤ったインクリメンタルバックアップをもたらす可能性がありました。また、このようなVMページの必要時のフルページイメージWAL出力も行なわれておらず、壊れたページ書き込みが修正されないままとなる可能性がありました。これは後にIndex Only Scanでの誤った問い合わせ結果が生じるなどの、誤動作を引き起こすおそれがあります。
</p>
<p>
既存のバックアップやアーカイブWALに潜在的にデータ破損が含まれていることに留意してください。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=56bf5fa5d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d0fb1da21">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7edec8b57">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b01c31eef">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f581fa729">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c0d9864f5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9171f77db">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4d7feebfb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=067213430">&#167;</a></small></p>
<li>WALサマライズ処理でのタイムライン変更時のハングアップが防止されました。  (Robert Haas) (18)(17)</li>
<p>
スタンバイサーバで、以下のログメッセージがwalsummarizerプロセスから継続的に出力される動作が報告されました。
</p>
<pre>
ERROR:  could not read WAL from timeline .. at ...: invalid record length ...
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dfb96277d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=18f0de6b8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=499d9eabb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bdcea66f0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1d299d6ab">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d28cdf46e">&#167;</a></small></p>
<li>スタンバイ昇格のときのロジカルデコーディングのタイムライン選択で、競合状態が修正されました。  (Bertrand Drouvot) (18)(17)(16)</li>
<p>
スタンバイ側で実行中のロジカルデコーディングが「ERROR:  requested WAL segment has already been removed」で失敗する可能性がありました。再試行すれば成功するため恒久的な問題はありませんが、可用性としては有害でした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b4bd13850">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=16b89ff04">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8cd687c44">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2a04624da">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4bff3aa51">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ab5334d8b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d9b49e5b4">&#167;</a></small></p>
<li>タイムラインを切替するときのwalreceiverの接続文字列の露出が回避されました。  (Chao Li) (18)(17)(16)(15)(14)</li>
<p>
pg_stat_wal_receiverビューは機微なデータを除いてサニタイズされた接続文字列を見せるべきです。しかし、タイムライン切替に際して既存のwalreceiverプロセスを再利用するときに、一時的に完全な接続文字列を見せてしまっていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b903d1792">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c89499a79">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e037a4199">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=065cbfb88">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e18b77153">&#167;</a></small></p>
<li>ロジカルレプリケーションで受け取ったタプルの列数が正しいかの検証を、アサートではなく実行時チェックで行うようになりました。  (Varik Matevosyan) (18)(17)(16)(15)(14)</li>
<p>
悪意の、または、壊れたパブリッシャは一貫性のない列数を送出するかもしれません。これによる深刻な悪影響をおよぼすシナリオは見つからなかったものの、より注意を払うべきと判断されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dc3db3a83">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=15f4e3d0c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=59759e1a5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=871d4f5b6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=510a05f07">&#167;</a></small></p>
<li>レプリケーションコマンド内の文字列パラメータへのクォート付加について、実装がクリーンアップされました。  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
レプリケーションコマンドを生成する様々な個所で、コマンドに挿入されるレプリケーションスロット名や他のパラメータのクォート付加について、十分な注意が払われていませんでした。そのため、レプリケーションコマンドで予期せぬエラーが発生するおそれがありました。
</p>
<p>
原理的には作りこまれたレプリケーションスロット名でSQLインジェクションも可能でした。ただし、ほとんどの場合、元からSQL実行が可能な管理者が行う操作であるため、実用的な害はないと考えられます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=abb582555">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=14810cc0d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=26d6c19d0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=819e5b964">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2a00840e8">&#167;</a></small></p>
<li>空のプリペアドトランザクションのロジカルデコーディングについて修正されました。  (Masahiko Sawada) (18)(17)(16)(15)(14)</li>
<p>
デコード可能な変更を起こさないプリペアドトランザクションは、先立つ「PREPARE」無しに、「COMMIT PREPARED」や「ROLLBACK PREPARED」を出力プラグインに送出していました。組み込みのサブスクライバでは、これはレプリケーションを壊します。他のプラグインでも同様に問題となると考えられます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2289e65e1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b563fc6bd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8c4519c71">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=744618346">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0dbfb8520">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c2d34db0a">&#167;</a></small></p>
<li>スタンバイ昇格後のUNLOGGEDシーケンスのデータ破損が修正されました。  (Fujii Masao) (18)(17)(16)(15)</li>
<p>
これまでは、プライマリで作られてスタンバイにレプリケートされたUNLOGGEDシーケンスに、スタンバイ昇格後にアクセスすると、「ERROR:  bad magic number in sequence」などのエラーや、アサート失敗が発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=22af34b98">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=627605713">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a1ed6a9a0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=913d3b610">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d2980067b">&#167;</a></small></p>
<li>カスケードスタンバイでのWALアーカイブによるリカバリからストリーミングに復帰するときの再接続失敗が、修正されました。  (Marco Nenciarini) (18)(17)(16)(15)(14)</li>
<p>
このとき「ERROR:  requested starting point ... is ahead of the WAL flush position」が発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bef46aed3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=331016322">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2cf28d1b9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5dbeb69bc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8f64cc83f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5fb3c6389">&#167;</a></small></p>
<li>WALリプレイが一貫性のあるデータベース状態に達する前にホットスタンバイ接続を受け付ける動作が防止されました。  (Nikhil Sontakke) (18)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7673dfe77">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=311e66df9">&#167;</a></small></p>
<li>スタンバイサーバで、ローカルにpg_database.dathasloginevtのクリアを試みないようになりました。  (Ayush Tiwari) (18)(17)</li>
<p>
スタンバイで実行が試みられていましたが、これは機能しておらず、また、プライマリでの変化がすぐに反映されて上書きされるので不要な動作でした。
</p>
<p>
loginのイベントトリガを削除した後にスタンバイに接続したときに、「FATAL:  cannot acquire lock mode AccessExclusiveLock on database objects while recovery is in progress」が出て接続できない動作が報告されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=97b5c5aaa">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4a375527a">&#167;</a></small></p>
<li>使われなくなったレプリケーションスロットを削除するときの競合状態が回避されました。  (Xuneng Zhou) (18)(17)</li>
<p>
削除直後のスロットの共有メモリエントリを他セッションが再利用した場合、誤ったロック解放と誤ったログメッセージ（異なるスロット名やデータベースOIDが使われる）が生じる可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=08458bcae">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ea834d747">&#167;</a></small></p>
<li>一時的なレプリケーションスロット（初期化途中の論理レプリケーションスロット）を削除するときの競合状態が回避されました。  (Zhijie Hou) (18)(17)(16)(15)(14)</li>
<p>
これまでの実装では、スロットを解放した後にスロットの共有メモリエントリにいくらか追加的な更新を実行していました。これは他セッションが直ちに再利用するかもしれないため、安全ではありません。本修正で、一時スロットには、この更新を行なわないようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f833c9207">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=080d61f07">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=51e79222c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a4eb59d40">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=968c50845">&#167;</a></small></p>
<li>ロジカルレプリケーションのテーブル初期同期で、進捗報告が古い内容となっていた問題が修正されました。  (Shinya Kato) (18)(17)(16)(15)(14)</li>
<p>
これまでは、サブスクライバのpg_stat_progress_copyビューは、データコピーが終わった後でも、初期COPY操作をアクティブとして表示していました。同期がパブリッシャに追いつくまで、古いエントリが表示されたままでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d9cd9b4d7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f2acab534">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d140237da">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b5f7e7569">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e3c4e3746">&#167;</a></small></p>
<li>バックアップに失敗したなら、ベースバックアップの進捗がクリアされるようになりました。  (Chao Li) (18)(17)(16)(15)</li>
<p>
これまで、pg_stat_progress_basebackupビューは、レプリケーションクライアントが切断するまで、古い進捗情報を表示し続けていました。標準付属のpg_basebackupであれば、失敗した後に即座に切断しますが、他のバックアップを取得するクライアントはそうであるとは限りません。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b70000837">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e7564ee8c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e2ea6bfed">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7cbd80340">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cf7530cf7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e2ad214dd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a240e8cd2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fffa4d870">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a8fb98b7b">&#167;</a></small></p>
<li>設定track_functionsが有効であるとき、実行時統計情報(pgstats)のエントリの同時削除のためにPANICが生じる可能性があり、修正されました。  (Sami Imseih, Michael Paquier) (18)(17)(16)(15)</li>
<p>
「PANIC:  cannot abort transaction .., it was already committed」が出るケースが報告されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5cc59834b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2e0c61aed">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bf4616b59">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1e9e62193">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8a4f389dd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=39e649d44">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7c457ea15">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=75aca8b93">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fe464e9e6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=afb076b29">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e34b1ff5d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9e4771825">&#167;</a></small></p>
<li>対応する共有ハッシュテーブルのエントリに対するメモリ領域取得に失敗した後、壊れた実行時統計情報(pgstats)のローカルエントリをクリーンアップするようになりました。  (Niall Newman) (18)(17)(16)(15)</li>
<p>これを行なっていなかったため、次にローカルエントリが使われたときに、NULLポインタ参照によるクラッシュが発生しました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=89fc6a7c1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2fd8d45ec">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fc9283b21">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=636bcd6a5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=10e20e59e">&#167;</a><br />
</small></p>
<li>読み込みや書き込みの失敗後に誤ったI/O操作統計が記録されないように、修正されました。  (Bertrand Drouvot) (18)</li>
<p>
各種のWAL読み書きに処理に失敗したときにエラーを意味する負の値がそのまま統計値のカウントに使われていて、pg_stat_ioビューなどで参照されるWALのI/O統計に誤った値が混入する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=13f940b4b">&#167;</a></small></p>
<li>PL/Perlで、不正なPostgreSQL::InServer::ARRAYオブジェクトを扱うときのNULLポインタ参照によるクラッシュが回避されるようになりました。  (Xing Guo) (18)(17)(16)(15)(14)</li>
<p>
PostgreSQL::InServer::ARRAYはPL/Perl関数に引数でPostgreSQLの配列を渡すときに使われるperlのオブジェクト型です。PL/Perl関数からPostgreSQLの配列を返すときにも使用できます。検査が不足していて、引数に由来せず適切な内部構造を持たないPostgreSQL::InServer::ARRAYオブジェクトを返すとクラッシュを引き起こせました。
</p>
<pre>
（クラッシュ発生例）
=# CREATE FUNCTION f102() RETURNS integer[] AS $$
     return bless {}, "PostgreSQL::InServer::ARRAY"; $$ LANGUAGE plperl;
=# SELECT f102();
server closed the connection unexpectedly
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e430ecc59">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d424d06ed">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3854f4afc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9b2a6ccc4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e520ad34b">&#167;</a></small></p>
<li>PL/Pythonで、Pythonのシーケンスオブジェクトとマッピングオブジェクトを扱うときにエラーを正しく検査するようになりました。  (Richard Guo) (18)(17)(16)(15)(14)</li>
<p>
hstore_plpython拡張やjsonb_plpython拡張を使って、PL/Python関数の戻り値をhsotre型やjsonb型に変換している場合に該当する問題です。これまでは、壊れたオブジェクトやハンドルされない例外によって、NULLポインタ参照によるクラッシュが発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=53482fcb9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3dc59c173">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e92f23bde">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=12bff46ff">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0b7719f74">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=309dc4526">&#167;</a></small></p>
<li>libpqで、pqReadData()の実行中にSSLまたはGSSの復号バッファに残っている未処理バイトを常にすべて取り出すようになりました。  (Jacob Champion) (18)(17)(16)(15)(14)</li>
<p>
例外的なケースですが、大きなメッセージのサーバからの届き方によっては、バッファがいっぱいになることでlibpqがソケット到着を誤って待ち続けて、APIを呼び出すクライアントアプリケーションがハングアップしてしまう可能性がありました。
</p>
<p>
pqReadData()はサーバ側からデータを読むlibpqの内部実装関数です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=eeb2940ae">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2167302b7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c162810a5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d3f329656">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4ecba7fa3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1b018b5d1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7f8745543">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bb0a54518">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=177a2a2e3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=477bc27a5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=05908afcd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d3888c90a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=536512f34">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=27761c015">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0958c3ea4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6243ea6c3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=21a6c69ea">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f5f569713">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d9eb70c9c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=87c3a79ea">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bab0a2db7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=56988064b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5ba13f8c0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7532f2117">&#167;</a></small></p>
<li>libpqのメモリ不足状態の処理が改善されました。  (Anthonin Bonnefoy) (18)</li>
<p>
COPYデータ読み込みや関数呼び出しの途中に、非同期メッセージ処理でメモリ不足になった場合にも、直ちにエラーを出すようになりました。これまでは、セッション切断された状態で処理が継続されていて、エラー発生が遅れたり、不適切なエラーが出る可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8380013cd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6b46a5d1b">&#167;</a></small></p>
<li>libpqのトレース機能が、新しい形式のBackendKeyDataメッセージとCancelRequestメッセージを正しく出力するようになりました。  (Anthonin Bonnefoy) (18)</li>
<p>
これらのプロトコルメッセージは固定長から可変長に仕様変更されましたが、トレース機能では固定長を想定したままとなっていたため、「mismatched message length」という警告が出力されていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0766bc57e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dd5eca055">&#167;</a></small></p>
<li>libpqが30000バイトを超えるParameterDescriptionメッセージを受け付けられるようになりました。  (Ning Sun) (18)(17)(16)(15)(14)</li>
<p>
libpqは受信メッセージの妥当性検査として、「長くなりうるメッセージ型」以外について長すぎるメッセージを弾きます。ParameterDescriptionは「長くなりうるメッセージ型」として扱われていなかったため、メッセージ長が30000バイトを超えるとエラーになっていました。この制限により、7498個を超えるパラメータを持つプリペアドステートメントに対するPQdescribePrepared()が失敗していました。この数のパラメータはまれな用法ですが仕様の範囲内です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b1ab4bc52">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e4183c667">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8d516d2b9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0f63b74a4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1b79c8d1a">&#167;</a></small></p>
<li>ecpgコンパイラのNULLポインタ参照によるクラッシュが修正されました。  (Jehan-Guillaume de Rorthais) (18)</li>
<p>
構造体の内側に入れ子になった共用体を含むDECLAREセクションをもつ.pgcコードを変換しようとすると、ecpgコマンド実行がクラッシュしました。
</p>
<pre>
（ecpgコマンドがクラッシュするコード例）
EXEC SQL BEGIN DECLARE SECTION;
    struct s1
    {
        char STR1[10];
        union u1
        {
             int NUM1;
             int NUM2;
        } U1;
    } S1;
EXEC SQL END DECLARE SECTION;
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=917fdbc63">&#167;</a></small></p>
<li>ecpgのGET DESCRIPTOR文とSET DESCRIPTOR文で、記述子ヘッダ項目を複数指定する構文が拒否されるようになりました。  (Masashi Kamura) (18)(17)(16)(15)(14)</li>
<p>
これまでも文法上はこの構文が許されていましたが、実装は実際には複数のヘッダ項目に対応できておらず、指定すると壊れたCコードが生成されていました。
</p>
<p>
本修正で構文解析処理でもドキュメント上でもヘッダ項目は1つだけに変更されました。これは非互換性を含む変更です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=081434b0f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fe8c0a762">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4d4b73cfd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bfeddcf09">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9e8fd9f7a">&#167;</a></small></p>
<li>psqlのパイプラインモードにおける遅延エラーの問題が修正されました。  (Michael Paquier) (18)</li>
<p>
Syncメッセージへの応答としてサーバがエラーを報告する場面（遅延制約の違反など）で、psqlがハングアップしたり、アサート失敗したりする可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1e9bc4074">&#167;</a></small></p>
<li>psqlの拡張表示（expanded）の整形出力で、行の幅が揃うようになりました。  (Pavel Stehule) (18)(17)(16)(15)(14)</li>
<p>
テーブルのデータ行がレコードヘッダ行より狭い場合、データ行の幅がレコードヘッダ行に合わせられず、次のように桁のずれた出力になっていました。
</p>
<pre>
（ずれた出力の例）

+-[ RECORD 1 ]-+
| a | 10 |
| b | 20 |
+---+----+

（修正後の出力例）

+-[ RECORD 1 ]-+
| a | 10       |
| b | 20       |
+---+----------+
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=07a6c262b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=efd885d05">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1edbe6695">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=022ba5c61">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a4ca91ea1">&#167;</a></small></p>
<li>psqlの特別変数WATCH_INTERVALについて、既定の上限が強制されるようになりました。  (Sven Klemm, Daniel Gustafsson) (18)</li>
<p>
大きすぎる値(1000000超)を設定しようとすると、psqlはエラーを報告するものの、その値を適用してしまっていました。修正後は、上限を超える値は拒否され、変数の値は変更されません。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e0c641ebb">&#167;</a></small></p>
<li>psqlの「\l+」でデータベースサイズを表示する権限検査が修正されました。  (Christoph Berg) (18)(17)(16)(15)(14)</li>
<p>
サーバ側のpg_database_size()は、pg_read_all_statsロールの権限を持つ利用者に対して、対象データベースへのCONNECT権限がなくてもすべてのデータベースのサイズの参照を許します。しかしpsqlはこの仕組みを考慮せず、CONNECT権限を持つ利用者以外に対してはこの関数を呼び出していませんでした。
</p>
<p>
修正後は、「\l+」の権限検査にpg_read_all_statsロールの権限（USAGE）の確認が加わり、pg_database_size()の権限規則と一致するようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=77aeca802">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f2d6cf880">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=41949c6f3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=844bc718a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e6e8a3078">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4e19081da">&#167;</a></small></p>
<li>psqlの「\df」のタブ補完で、プロシージャも候補に含めるようになりました。  (Erik Wienhold) (18)(17)(16)(15)(14)</li>
<p>
「\df」コマンド自体はプロシージャも表示対象に含めるよう拡張されていましたが、タブ補完の候補は関数だけを表示し続けていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=558e0de6d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=598af79b1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=355a4fcf9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f9afdb6d1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c25737c89">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2d44bb900">&#167;</a></small></p>
<li>pgbenchのスレッド安全性のバグが修正されました。  (Fujii Masao) (18)(17)(16)(15)</li>
<p>
pgbenchを複数スレッドで実行し、かつ「--verbose-errors」オプションを指定した場合、異なるスレッドが同じバッファを使ってエラーメッセージを組み立てようとし、ログ出力が壊れる可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=98dd6c204">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=52b3e7001">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6432a4cd6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f18fcd9a4">&#167;</a></small></p>
<li>pg_combinebackupで、コピー元ファイルが想定より小さい場合に無限ループが発生することがあり、防止されました。  (Peter Eisentraut) (18)(17)</li>
<p>
「--copy-file-range」を指定して合成フルバックアップを再構築する過程で、ファイルが0バイトしかコピーできなかった場合をエラーとしていなかったため、試行が繰り返されてしまっていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d36b72894">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=090ce6934">&#167;</a></small></p>
<li>pg_createsubscriberで、エラー発生後にパブリッシャ側オブジェクトのクリーンアップが行なわれない場合があり、修正されました。  (Nisha Moond) (18)(17)</li>
<p>
pg_createsubscriberは、論理レプリケーションオブジェクトを作成した後にエラーを起こした場合、パブリッシャ上に作成したパブリケーションとレプリケーションスロットを削除する必要があります。一部のエラーケースでは削除が行われず、pg_createsubscriberの再実行のために手動での削除が必要でした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=196b4b5ae">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c03784a21">&#167;</a></small></p>
<li>pg_recvlogicalの出力ファイルが、ソースクラスタのグループ読み取り権限に従って作成されるようになりました。  (Fujii Masao) (18)(17)(16)(15)(14)</li>
<p>
pg_recvlogicalはこの挙動についてドキュメントに記載されていたにもかかわらず、実際にはソースクラスタのグループ読み取り権限を反映した書き出しが行なわれず、常にファイル所有者の読み書きのみを許すモードが使われていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=89b4b3ae3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ddd12d1a5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9590dcfca">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ba9833a75">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5552a15a3">&#167;</a></small></p>
<li>pg_restoreの「--statistics」および「--statistics-only」オプションの一貫しない挙動が修正されました。  (Chao Li, Michael Paquier) (18)</li>
<p>
「--schema」「--table」などの選択的リストアオプションと組み合わせた場合に意図通りの要素がリストアされませんでした。pg_dumpで対象選択オプションを組み合わせた場合と同様に動作するように修正されました。
</p>
<pre>
（誤動作例）
$ psql -d db1 &lt;&lt;EOS
CREATE TABLE t119 AS SELECT g id, g % 5 n FROM generate_series(1, 20) g;
CREATE STATISTICS s119 ON id, n FROM t119;
ANALYZE;
EOS

$ pg_dump --statistics -Fc db1 -f db1.dmp
（プランナ統計情報を含むダンプファイルを作る）

$ pg_restore --table t119 --statistics-only -f - db1.dmp
（→「t119テーブルの統計情報のみをリストア」の意図だが、リストア内容が空になる）

$ pg_restore --statistics --table t119 -f - db1.dmp
（→「統計情報を含めてt119テーブルをリストア」の意図だが、拡張統計情報が欠損する）
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=42ffdedcf">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=477efef08">&#167;</a></small></p>
<li>vacuumdbの「--missing-stats-only」が、パーティションテーブルに対する式インデックスを処理対象から除外するようになりました。  (Baji Shaik) (18)</li>
<p>
これまで、本オプションのvacuumdb実行では、パーティションテーブルに式インデックスがあると、常にそのパーティションテーブルにANALYZEを実行しようとしていました。しかし、統計情報は子パーティションのインデックスに作成されても、パーティションテーブルのインデックスには作成されないため、意味がありませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7e085aabd">&#167;</a></small></p>
<li>contrib/amcheckで、btreeインデックスのメタページの「allequalimage」フラグの破損が報告されない問題が修正されました。  (Chao Li) (18)</li>
<p>
btreeインデックスを検査する関数は、これまでインデックスキー列のいずれかにinterval_ops演算子クラスを含む場合のみ正しく動作していて、そうでないインデックスでこの破損が見逃される可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=12c32bbc8">&#167;</a></small></p>
<li>contrib/amcheckの GINインデックス検証関数でメモリリークが修正されました。問い合わせが終わるまで未開放メモリが蓄積します。  (Kirill Reshke) (18)</li>
<p>
大きなGINインデックスの検証でメモリ使用量が増大するおそれがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=80cfd8aef">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1f8ab91c1">&#167;</a></small></p>
<li>contrib/amcheckで、ショートヘッダのvarlenaデータムが正しく扱われるように修正されました。  (Andrey Borodin) (18)(17)(16)(15)(14)</li>
<p>
この誤りで、btreeインデックス検証で無駄な処理が生じる可能性がありますが、それ以上の悪影響は無いと考えられます。
</p>
<p>
varlenaデータムとはPostgreSQL実装内で使われる長さとデータ本体からなるデータ構造です。ショートヘッダは長さをあらわすのに1バイトだけ使う形式です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=897e79486">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8abb8a155">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c89a1ca01">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4284476c0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=af09b18cb">&#167;</a></small></p>
<li>contrib/btree_gistで、float4とfloat8の演算子クラスにおける「NaN」の扱いが修正されました。  (Bill Kim, Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
各種の比較関数と、GiSTのpenalty関数、distance関数が「NaN」を考慮しておらず、「NaN」を渡されたときに誤った結果を返していました。
</p>
<p>
本修正の適用後、float列のbtree_gistインデックスに「NaN」のエントリが含まれる可能性がある場合は、それらのインデックスの再構築を推奨します。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a47005f0b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1e1d07792">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d215d2cc2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d569ccd40">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=98dd4406f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=255bce448">&#167;</a></small></p>
<li>contrib/btree_gistで、GiSTインデックス構築時のbit型とvarbit型の値のソートが修正されました。  (Tom Lane) (18)</li>
<p>
これまでbit型の値がbytea型であるかのようにソートされていました。これは明白な誤動作を引き起こすことはありませんでしたが、型本来のソート順に一致しない並びで構築されるため、非効率なインデックスになりました。
</p>
<p>
本修正の適用後、bit列上のbtree_gistインデックスの再構築を推奨します。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=11cb9c431">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=558c4ea9a">&#167;</a></small></p>
<li>contrib/btree_gistで、非等価（<>）演算子を使った検索が修正されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)</li>
<p>
可変長データ型の場合、非リーフインデックスページを走査するコードが誤った比較関数を適用していました。これは誤った問い合わせ結果、および場合によってはクラッシュにつながる可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fc6649abe">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=12c519207">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=86992769e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0663382c9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8f2a1b3d3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=286f9a3ce">&#167;</a></small></p>
<li>contrib/dblinkとcontrib/postgres_fdwで、use_scram_passthroughオプションについて、ユーザマッピングの設定が外部サーバの設定より優先されるよう修正されました。  (Matheus Alcantara) (18)</li>
<p>
これまでは外部サーバ側の設定が優先されていましたが、これは他の外部テーブルオプションの挙動と一貫していませんでした。他の接続オプション（sslcertやsslkeyなど）と同様に、外部サーバのオプションは共通のデフォルト値を提供し、ユーザマッピングのオプションがそれを上書きする扱いに統一されました。
</p>
<p>
これは非互換性を含む変更と言えます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=88d7748d2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=130396e6c">&#167;</a></small></p>
<li>contrib/dblinkの外部データラッパのuse_scram_passthroughオプションが拒否されるようになりました。  (Matheus Alcantara) (18)</li>
<p>
このオプションは外部サーバとユーザマッピングに対してのみ意味を持ちますが、dblinkは外部データラッパ（dblink_fdw）レベルでもこのオプションを受け付けていました（そして受け付けた設定を無視していました）。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cd777e27e">&#167;</a></small></p>
<li>contrib/hstore_plperl、contrib/jsonb_plperl、contrib/jsonb_plpythonで保護されていない再帰とループがあり、修正されました。  (Aleksander Alekseev) (18)(17)(16)(15)(14)</li>
<p>
深くネストしたjsonb値を扱うときのスタックオーバーフロー（によるクラッシュ）が防止されました。また、Perlのオブジェクト参照の循環チェーンをたどるときに生じる無限ループが割り込み可能になりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e3b7a43fa">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3df0b7755">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b0f3465b6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a6f23c3ad">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=639fff511">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d65cf6f80">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4efef9d18">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=60a1d712a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4fbbabb0a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1f6b2295f">&#167;</a></small></p>
<li>contrib/intarrayでプランナ統計情報のカタログキャッシュエントリの解放漏れが修正されました。  (Man Zeng) (18)(17)(16)(15)(14)</li>
<p>
この解放漏れにより、「WARNING:  resource was not closed: cache pg_statistic ..」のような警告が発生していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e7544c518">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=94b57ab54">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=273be484a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=702a6d5f6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a96b051a9">&#167;</a></small></p>
<li>contrib/ltreeで比較関数における整数オーバーフローが修正されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)</li>
<p>
約14,653個を超えるラベルを含むltree値は、オーバーフローによって誤った比較結果を返していました。btreeインデックスにそのような値が含まれている場合、破損している可能性があるため、本修正の適用後に再構築することを推奨します。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c3e36a9a5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c391c00d9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=aca944e33">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1bec6b1c1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f528a5606">&#167;</a></small></p>
<li>contrib/pgcryptoで、OSSLCipherオブジェクトの使用中にエラーが発生した後の二重解放によるクラッシュが回避されました。  (Yuelin Wang) (18)(17)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=020426268">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2aa6be6e6">&#167;</a></small></p>
<li>contrib/pg_prewarmのautoprewarmワーカの範囲外アクセスが修正されました。  (Matheus Alcantara) (18)</li>
<p>
このコードは、配列の末尾の1つ先から値を取り出そうとしており、セグメンテーション違反によるクラッシュを引き起こす可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3bf2cb225">&#167;</a></small></p>
<li>contrib/pg_surgeryのheap_force_kill関数とheap_force_freeze関数で、配列の範囲外書き込みが修正されました。  (Michael Paquier) (18)(17)(16)(15)(14)</li>
<p>
オフセット番号がMaxHeapTuplesPerPage（ページあたりの最大タプル数、291など）に等しいTIDを変更しようとすると、確保された配列の末尾の1バイト先に書き込み、サーバをクラッシュさせる可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2b09f8a91">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0bcf19c9e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=daf8bc7d4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=51f63ba2b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1eda3eb07">&#167;</a></small></p>
<li>contrib/pg_surgeryで、64K要素を超えるTID配列による無限ループが回避されるようになりました。  (Andrey Rachitskiy) (18)(17)(16)(15)(14)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1f24c8237">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=19f0391df">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1b6c99d96">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=eb28b6f24">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=395700f48">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e9d53cf45">&#167;</a></small></p>
<li>contrib/spiのrefint拡張で、check_foreign_key()関数のNULLポインタ参照が回避されました。  (Ayush Tiwari) (18)(17)(16)(15)(14)</li>
<p>
ON UPDATE CASCADEの場合、参照列の新しいキー値がNULLであると、クラッシュが発生していました。これはCVE-2026-6637の修正の見落しですが、その前からあったコードも正しいものではありませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ed0c4d5af">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6b4de201e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=eb93f10e2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=77b2d18e9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1de0a711d">&#167;</a></small></p>
<li>contrib/segで、確実性指示子「~」を持つセグメントの値が正しく出力されるように修正されました。  (Ewan Young) (18)(17)(16)(15)(14)</li>
<p>
seg型の出力関数seg_out()はセグメントの上限に付いた「~」を出力していませんでした。さらに悪いことに、下限に「~」があり上限に指示子がない場合、上限がまったく出力されませんでした。なお、文字列としての出力が不正であるだけで、演算結果に影響はありません。
</p>
<pre>
（誤動作例：2番目と3番目が誤動作）
db1=# SELECT '~1 .. ~5'::seg, '1 .. ~5'::seg, '~1 .. 5'::seg;
   seg    |  seg   |  seg
----------+--------+--------
 ~1 .. ~5 | 1 .. 5 | ~1 ..
(1 row)
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0004cab4d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bcbbd070d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=504ca0513">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b3aa2083a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=58b91fc73">&#167;</a></small></p>
<li>contrib/xml2のxpath_nodeset()関数で名前空間ノードを問合せたときのクラッシュが修正されました。  (Andrey Chernyy, Michael Paquier) (18)(17)(16)(15)(14)</li>
<p>
以下のように、query引数に「//namespace::」を指定した場合にクラッシュするケースが報告されました。
</p>
<pre>
db1=# SELECT xpath_nodeset(
        '&lt;root xmlns:foo="http://example.com/foo"&gt;&lt;child/&gt;&lt;/root&gt;',
        '//namespace::*');
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=91b57eade">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4a49ab289">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=18955d412">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bc5775149">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f3f901a53">&#167;</a></small></p>
<li>OpenSSL 4を使ったPostgreSQLのビルドに対応しました。  (Daniel Gustafsson) (18)(17)(16)(15)(14)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=27cf3b5af">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8bcabfcce">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fb8befa7b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c7f70fa1b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=086652c02">&#167;</a></small></p>
<li>タイムゾーンデータファイルをtzdataリリース2026cに更新しました。  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
アルバータ州（America/Edmonton）は、2026年11月から年間を通したUTC-06（実質的に、恒久的なサマータイム）になります。このリリースでは、それ以降のタイムゾーン省略形は「CST」と仮定しています。この仮定は将来変更される可能性が高いのですが、新しい省略形に何が使われるかは明らかになっていません。
</p>
<p>
モロッコ（Africa/Casablanca）は、2026-09-20に、サマータイムの切り替えなしの恒久的なUTC+00に移行します。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3c16aa293">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5f67124fa">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=669438aed">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=796c275a0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=af7be5672">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=812cc1a73">&#167;</a></small></p>
<li>古いマイナーバージョンが生成したWALのリプレイ時の自己デッドロックが修正されました。  (Andrey Borodin) (16)(15)(14)</li>
<p>
この不具合は前回のマイナーリリース(16.14、15.18、14.23)で導入されました。より古いマイナーバージョンのプライマリに追従するスタンバイサーバで、startupプロセスがハングアップしてレプリケーションが先に進まなくなりました。
</p>
<p>
共有行ロックで使われるマルチトランザクションに関するWALレコードのリプレイで問題が発生しました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=42a3194e5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2dfe75f98">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2bb60eb4f">&#167;</a></small></p>
<li>変数が1つも渡されていない場合でも、未定義のjsonpath変数をエラーとして扱うようになりました。  (Andrey Rachitskiy) (16)(15)(14)</li>
<p>
jsonbの「@?」演算子と「@@」演算子がjsonpath式の中で使う変数を渡せない、という場合のコードパスでは、未知のjsonpath変数が、本来の期待であるエラーの発生ではなく、JSONのnullとして誤って扱われていました。期待される動作でないことに加えて、この誤りは無制限のメモリ消費を引き起こす可能性がありました。
</p>
<pre>
（誤動作例）
db1=# select '{"A":1}'::jsonb @@ '$"no_such_var" == 1';
 ?column?
----------
 f
(1 row)

db1=# SELECT '{"A":1}'::jsonb @? '$"no_such_var"';
 ?column?
----------
 t
(1 row)

（修正後は以下のエラーが出る）
ERROR:  could not find jsonpath variable "no_such_var"
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1daeef6e0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8af173e28">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=364014327">&#167;</a></small></p>
<li>Visual Studio 2026を使ったPostgreSQLのビルドに対応しました。  (Andrew Dunstan) (16)(15)(14)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bc5a873a8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=eba7f1dc0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f1c579fc4">&#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>

<div>
<div style="background-color: #fffacd; padding: 20px; border-radius: 8px; text-align: center;">2026/10/27（火）「PostgreSQL 19 リリース記念セミナー」開催！<br />
コントリビューターが新機能をわかりやすく解説します。<br />
詳しくは<a href="https://www.sraoss.co.jp/event_seminar/detail/20261027-postgresql19-webinar/?utm_source=techblog&amp;utm_medium=email&amp;utm_campaign=pg19-seminar" target="_blank" rel="noopener"><strong style="color: #2581c4;">こちら</strong></a>をご覧ください。</div>
</div>

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 17.10 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/17-10/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Thu, 28 May 2026 03:11:19 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 17]]></category>
		<category><![CDATA[PostgreSQL 17.10]]></category>
		<category><![CDATA[PostgreSQL 17.9]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=20718</guid>

					<description><![CDATA[このリリースは 17.9 からの修正リリース（2026年 5月 14日リリース）です。 17.X からのアップデートではダンプ、リストアは不要です。 しかしながら、17.6 よりも前のバージョンからアップデートする場合に ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 17.9 からの修正リリース（2026年 5月 14日リリース）です。<br />
17.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、17.6 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/17-6/" rel="noopener">17.6のリリース情報</a>も参照してください。</p>
<p><span id="more-20718"></span></p>
<h3>PostgreSQL 17.9 から 17.10 への変更点</h3>
<p>18.4, 17.10, 16.14, 15.18, 14.23 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>スタートアップパケットの処理での際限ない再帰を防止するようになりました。(CVE-2026-6479)  (Michael Paquier) (18)(17)(16)(15)(14)</li>
<p>
悪意のクライアントが、拒絶されたSSLとGSSの暗号化の要求を交互に何度も繰り返すことで、接続先バックエンドをクラッシュさせることができました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f7a191f53">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=32a4ce55c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=66cf26b9e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3fb66d302">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3b4e66739">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6dffaeb8e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c2e6ef863">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=16fda4df6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=14a4a7040">&#167;</a></small></p>
<li>メモリ割り当て計算における整数オーバーフローがいくつか修正されました。(CVE-2026-6473)  (Tom Lane, Nathan Bossart, Heikki Linnakangas) (18)(17)(16)(15)(14)</li>
<p>
様々な場所のメモリ割り当てサイズの計算で整数オーバーフローの可能性について不注意がありました。整数オーバーフローにより小さすぎるメモリ確保が行なわれて、その結果、範囲外に書き込みが行なわれて、サーバプロセスのクラッシュを引き起こす可能性がありました。また、おそらく任意コード実行も可能と考えられます。
</p>
<p>
全てとは言えませんが、この危険があるのは概ね 32ビットビルドだけです。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e1c30458a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fe2720c45">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cfb610eaa">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bfc5cea76">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=61a9b4b6e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=01e568b8c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=01b5ef7df">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=aff71f87b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4032c9d98">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e31ef0720">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f3cee4dc4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e3a2bea41">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a4f089c79">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7fdb0907e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=39bc8f2ca">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dd8af778d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=26dd3cac2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c25973124">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fb0bc321d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bcfd848e7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=55328e3a9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=87357a606">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=32c525eb6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=137013f60">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=986753361">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=67dd6243d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3c41f5534">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e24fb3247">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e49e9590d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8e81995de">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8d1489d50">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ebcfa7867">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f20b84081">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b11c3eadf">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3e0eba196">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c7fb9f765">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=00e243e67">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=924b3e943">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d75b1dc96">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=37842f3dc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e5babf754">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=47dae5e74">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d106295b6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6a423a256">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3fbec9e50">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8e909812d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e42598a41">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dc6c85ff4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c9447b8bd">&#167;</a></small></p>
<li>pg_createsubscriberコマンドで、オプションで指定されたサブスクリプション名を適切にクォートするようになりました。(CVE-2026-6476)  (Nathan Bossart) (18)(17)</li>
<p>
（ありそうにないことですが）信頼できない者がサブスクリプション名を任意に指定しているとして、サブスクリプション名にクォート無しのSQLコマンドを含めることで、SQLインジェクションが可能でした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c2e44c370">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d7de7fa84">&#167;</a></small></p>
<li>論理レプリケーションのオリジンの検査で、オブジェクト名を適切にクォートするようになりました。(CVE-2026-6638)  (Pavel Kohout) (18)(17)(16)</li>
<p>
「ALTER SUBSCRIPTION ... REFRESH PUBLICATION」はクォートを付加することなくSQLコマンドにスキーマ名とリレーション名を埋め込んでいて、これによりSQLインジェクションでパブリッシャ側で任意のSQL実行ができました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cb35d7306">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f0f59b658">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=248a433cd">&#167;</a></small></p>
<li>ts_headline()関数で長すぎるオプションをエラーを出して拒絶するようになりました。(CVE-2026-6473)  (Michael Paquier) (18)(17)(16)(15)(14)</li>
<p>
オプション「StartSel」「StopSel」「FragmentDelimiter」の文字列長は32Kbが上限でしたが、入力の検査が行われていませんでした。これを超える長い文字列の指定は、典型的にはサーバプロセスのクラッシュを引き起こしました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=62ad26266">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3ed3dbbf4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5919e0005">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7fe365693">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2d267ffc4">&#167;</a></small></p>
<li>列のMCV（最頻値）統計情報をリストアするときに、誤った入力を検出するようになりました。(CVE-2026-6575)  (Michael Paquier) (18)</li>
<p>
プランナ統計情報をリストアする関数はMCV統計値の検証が不十分でした。そのため、誤った値を受け入れて、後のプランナのクラッシュを引き起こすことがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=661095c40">&#167;</a></small></p>
<li>timeofday()およびpg_strfname()関数で、悪意のタイムゾーン名による攻撃を防ぐようになりました。(CVE-2026-6474)  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
作りこまれたタイムゾーン設定により、pg_strfname()関数に続いて実行されるsnprintf()関数のテンプレート文字列引数に「%」シーケンスを渡すことができました。これにより潜在的にクラッシュやサーバメモリ暴露を引き起こすことができました。また、pg_strftime()で使われるサイズに限りのある出力バッファのオーバーフローを起こすこともありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ba27389c2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4197c880c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=24e0e3254">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=126a236ba">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a50ae8306">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c6e7a9ef3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a386d14fe">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=79b7847c7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c3fff3950">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2c8226f52">&#167;</a></small></p>
<li>マルチ範囲型を作るときに、ユーザに指定されたスキーマに対するCREATE権限があることの確認が漏れており、修正されました。(CVE-2026-6472)  (Jelte Fennema-Nio) (18)(17)(16)(15)(14)</li>
<p>
マルチ範囲型は元となる範囲型と異なるスキーマに作成することが可能ですが、このときマルチ範囲型のスキーマについて権限確認が行なわれませんでした。
</p>
<pre>
（誤動作例：scm_without_privilegeに権限がなくともエラーなく実行できてしまう）
db1=> CREATE TYPE scm_with_privilege.typ1_range AS RANGE
        (SUBTYPE=int4, MULTIRANGE_TYPE_NAME=scm_without_privilege.typ1_multi)
CREATE TYPE
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a44780f41">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c27ba08cd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d92852d62">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=08c397b02">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8bca85e9f">&#167;</a></small></p>
<li>認証のコードでタイミング攻撃に安全な文字列比較を使うようになりました。(CVE-2026-6478)  (Michael Paquier) (18)(17)(16)(15)(14)</li>
<p>
これからはパスワードやハッシュ文字列などの検査で、memcpy()やstrcmp()に替えてtimingsafe_bcmp()を使用します。所要時間のデータ依存性がどれほど攻撃に有用であるかは不明ですが、安全のため置き換える判断がされました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d93ef4131">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c4e7435b3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=00e27235e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c95275f18">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4608619a1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8e34acfda">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1604939b2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9dcfcb92f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b282280e9">&#167;</a></small></p>
<li>libpqのPQfn()を安全でない関数であるとドキュメント記載し、libpq実装内部でも使用しないようになりました。(CVE-2026-6477)  (Nathan Bossart) (18)(17)(16)(15)(14)</li>
<p>
非整数の結果型に対してPQfn()には出力バッファのサイズが渡されないため、サーバから返ったデータのサイズが一致するか検査できません。悪意のサーバはこれを使ってクライアントのメモリを上書きできました。PQfn()は既に「廃れたもの」とドキュメント記載されていました。
</p>
<p>
PQfn()をresult_is_int引数に0を指定して使用しているクライアントで危険性を回避するには、使用するAPIを変更するほかありません。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=be0136440">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d88c7be15">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=614474996">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e3a1f83ea">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8ac723b2b">&#167;</a></small></p>
<li>pg_basebackupとpg_rewindでパス横断が防止されました。(CVE-2026-6475)  (Michael Paquier) (18)(17)(16)(15)(14)</li>
<p>
これらのアプリケーションでは入力から読み込まれた出力ファイルのパスを検証できていませんでした。そのため、（PostgreSQLサーバ側の）入力を与える悪意の者がこれらのアプリケーションにクライアント側の任意のファイル上書きをさせることができました。これからは絶対パスと親ディレクトリ参照を含むパスを拒絶するようになります。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6a67c540a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8f881e188">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6778af13e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0c83fe8e4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=498829dca">&#167;</a></small></p>
<li>contrib/intarrayのquery_int型とcontrib/ltreeのltxtquery型の中で、フィールドのオーバーフローが防止されました。(CVE-2026-6473)  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
16ビットのフィールドがオーバーフローを起こすか検査されていなかったため、これらのデータ型として多すぎる要素数を持つ値を与えると、問合せを実行したバックエンドプロセスのクラッシュが発生する可能性がありました。これから、そのような値は ERROR になります。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c5790ec4f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c4d04cc48">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5c1069c35">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=84a9f2641">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=074702525">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=05e73b5c3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2b429d887">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6f0bff33d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fc1fd3d97">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=479823a71">&#167;</a></small></p>
<li>contrib/ltreeのlquery型の長すぎる値を防止するようになりました。(CVE-2026-6473)  (Michael Paquier) (18)(17)(16)(15)(14)</li>
<p>
64Kアイテムを超える値は内部オーバーフローを起こしていて、潜在的にスタック破壊や誤った問い合わせ結果をもたらすおそれがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7f019f341">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8c3426110">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6b6b26fde">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9c2fa5b6a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b545c3787">&#167;</a></small></p>
<li>contrib/spiでSQLインジェクションとバッファオーバーランが防止されました。(CVE-2026-6637)  (Nathan Bossart) (18)(17)(16)(15)(14)</li>
<p>
check_foreign_key()関数はキー値のクォート付加が不十分で、また、クエリの組み立てに固定長のバッファを使用していました。このモジュールはサンプルコードにすぎないとはいえ、このような危険な誤りは含まれるべきでないため、修正されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1ebda7da9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2dc64ef28">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=710995782">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8053235ab">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2b026df29">&#167;</a></small></p>
<li>照合順序を適用できる型では、等価条件が一意性を示すものと仮定するのでなく、非決定論的照合順序を検査するようになりました。  (Richard Guo) (18)(17)(16)(15)(14)</li>
<p>
多数のプランナ最適化がこれを仮定していました。例えば、一意性インデックスがx列にあれば、ある1行だけが「WHERE x = 'abc'」を満たします。しかしながら、WHERE句にインデックスと異なる照合順序が付加されている場合、この結論は一般には安全ではありません。両方の照合順序が決定論的であるときは文字列の等価がビット単位での等価を意味するため安全ですが、非決定論的な場合にはそのように動作しないため、WHERE句またはインデックスに非決定論的な照合順序が適用される場合に、一意性を前提とした最適化で、誤った問い合わせ結果が返される可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e8fd5e579">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1132af22c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5c214b58b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b62f514ac">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d0e73bb18">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=748fe9e60">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=872c9fae7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8395446df">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bed3ffbf9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=13226050e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5a24cef08">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bab4f7fa5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=172034f6e">&#167;</a></small></p>
<li>結合の削除時に、RestrictInfo構造体内のリレーション参照が完全に削除されない問題が修正されました。  (Tom Lane) (18)(17)(16)</li>
<p>
この見落としにより、「ERROR:  FULL JOIN is only supported with merge-joinable or hash-joinable join conditions」といった予期しないプランナでのエラーを引き起こすことが判明しています。また、他のケースでも有効なプランが考慮されない原因となっていた可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=16fb94605">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=766d40286">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d509be4ac">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=53cb4ec1d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=798dabe83">&#167;</a></small></p>
<li>プランナによるパーティションキー列とサブクエリ出力の照合が改善されました。  (Richard Guo) (18)</li>
<p>
オペランドをパーティションキーと比較する前に、オペランドから何もしない（no-opの）PlaceHolderVarsを削除します。この変更により、以前はパーティションのスキャンが不要であると認識できなかった場合でも、パーティションプルーニングが正常に実行されるようになります。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8e8b2bef7">&#167;</a></small></p>
<li>「ON t1.boolcol」のようなboolean型の列のみで構成される結合句を処理できるように、自己結合の削除処理が修正されました。  (Andrei Lepikhov, Tender Wang, Alexander Korotkov) (18)</li>
<p>
以前は、このような場合に「ERROR:  no relation entry for relid ...」が発生していました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e8b9d6497">&#167;</a></small></p>
<li>仮想生成列を持つテーブルで、カーソルを使った更新「UPDATE/DELETE ... WHERE CURRENT OF」が正常に動作するように修正されました。  (Satyanarayana Narlapuram, Dean Rasheed) (18)</li>
<p>
これまでは、実行時に「ERROR:  WHERE CURRENT OF on a view is not implemented」が発生する動作が報告されていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f3d03fbd5">&#167;</a></small></p>
<li>「INSERT ... ON CONFLICT」内のEXCLUDED列参照における仮想生成列の展開が修正されました。  (Satyanarayana Narlapuram, Dean Rasheed) (18)</li>
<p>
不具合によって、予期せぬエラー「ERROR:  unexpected virtual generated column reference」が発生したり、誤った問い合わせ結果が発生したりしていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cf38dedf6">&#167;</a></small></p>
<li>ルールアクションおよびルール条件における「NEW」生成列の誤った処理が修正されました。  (Richard Guo, Dean Rasheed) (18)(17)(16)(15)(14)</li>
<p>
以前は、このような列参照がINSERTの場合にNULLとなり、UPDATEの場合にはOLDと同じ値になっていました。
</p>
<pre>
（誤動作例）
db1=# CREATE TABLE t21 (id int PRIMARY KEY, a int,
        gen int GENERATED ALWAYS AS (a * 2) VIRTUAL);
db1=# CREATE TABLE t21log (op text, old_gen int, new_gen int);
db1=# CREATE RULE r21i AS ON INSERT TO t21 DO ALSO
        INSERT INTO t21log VALUES ('I', NULL, NEW.gen);
db1=# CREATE RULE r21u AS ON UPDATE TO t21 DO ALSO
        INSERT INTO t21log VALUES ('U', OLD.gen, NEW.gen);
db1=# INSERT INTO t21 (id, a) VALUES (1, 10);
db1=# UPDATE t21 SET a = 100 WHERE id = 1;
db1=# SELECT * FROM t21log;
 op | old_gen | new_gen
----+---------+---------
 I  |  *null* |  *null*
 U  |      20 |      20
(2 rows)
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e528bfe97">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9d6208939">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=07b257189">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7062bd577">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8e39951be">&#167;</a></small></p>
<li>偽性のエラー「ERROR:  indexes on virtual generated columns are not supported」が修正されました。  (Robert Haas) (18)</li>
<p>
式インデックスの作成時に、このエラーが誤って報告されることがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cceb9c18a">&#167;</a></small></p>
<li>偽性のエラー「ERROR:  generated columns are not supported in COPY FROM WHERE conditions」が修正されました。  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
「COPY t23 FROM stdin WHERE tableoid > 0」のように「COPY FROM」のWHERE句でシステム列を使用すると、このエラーが誤って報告されることがありました。アサート有効のビルドでのアサート失敗も報告されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=11c2c0cc8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=681a91d29">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3c7a6bbe6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=07e833e3c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=40fa04e7c">&#167;</a></small></p>
<li>MERGEがrepeatable readモードまたはserializableモードで同時更新されるタプルを検出した場合に、「ERROR:  could not serialize access due to concurrent update」を出して直列化失敗を正しく報告するようになりました。  (Tender Wang) (18)(17)(16)(15)</li>
<p>
以前は、このような場合により低い分離レベルの場合と同じ動作をしていて、トランザクションがアボートせず、不整合が見過ごされる可能性がありました。
</p>
<pre>
（誤動作例 - 字下げは並行する別セッションをあらわします）
db1=# CREATE TABLE t24 (id int, v int);
db1=# INSERT INTO t24 VALUES (1,0);

　　　db1=# BEGIN;
　　　db1=*# UPDATE t24 SET v = v + 100;

db1=# START TRANSACTION ISOLATION LEVEL serializable;
db1=*# MERGE INTO t24 t USING (VALUES (1, 100)) AS s (id, inc) ON t.id = s.id
         WHEN MATCHED THEN UPDATE SET v = t.v + s.inc
         WHEN NOT MATCHED THEN INSERT (id, v) VALUES (s.id, s.inc);

　　　db1=*# COMMIT;

db1=*# SELECT * FROM t24;
 id |  v
----+-----
  1 |   0
  1 | 200
(2 rows)

db1=*# COMMIT;
db1=# SELECT * FROM t24;
 id |  v
----+-----
  1 | 200
(1 row)
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=13fab378e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2dcac93c0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f6e63d4b8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8bfaae6fb">&#167;</a></small></p>
<li>ソーステーブルから列が削除されている場合における「CREATE TABLE ... LIKE ... INCLUDING STATISTICS」の動作が修正されました。  (Julien Tachoires) (18)(17)(16)(15)(14)</li>
<p>
LIKEで指定するテーブルが作成後にALTER TABLEで列の削除を行なっているときに該当します。このような場合、拡張統計オブジェクトが正しくコピーされなかったり、コマンドが下記のような予期せぬエラーを返す可能性がありました。
</p>
<pre>
ERROR:  cache lookup failed for attribute 3 of relation 17106
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=149c875fc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a0104b447">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7bb519635">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=76d15a7ee">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=81b56b47c">&#167;</a></small></p>
<li>「ALTER INDEX ... ATTACH PARTITION」で、そうすべき場合には親インデックスを有効とマークできるようになりました。  (Sami Imseih) (18)(17)(16)(15)(14)</li>
<p>
すべてのリーフインデックスが有効であるにもかかわらず、パーティションインデックスが無効とマークされたままになる特殊なケースが存在していました。本修正は、ユーザが手動でカタログを更新することなく、このような状況を補正する仕組みを提供します。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5713ac248">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=becf6d269">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=313355d68">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0859000d0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d809b16d1">&#167;</a></small></p>
<li>「ALTER TABLE ... SET NOT NULL」がシステムテーブル（カタログ）の変更が完了した後にのみオブジェクトアクセスフック関数を呼び出すように修正されました。  (Artur Zakirov) (18)</li>
<p>
これはpg_constraintにNOT NULL制約用の行が追加された際につくられた不具合の修正です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6958077ce">&#167;</a></small></p>
<li>ALTER FOREIGN DATA WRAPPERが、ラッパーオブジェクトのハンドラ関数への依存関係を削除しないように修正されました。  (Jeff Davis) (18)(17)(16)(15)(14)</li>
<p>
以前は、VALIDATORパラメータの指定により、誤ってハンドラ関数への依存関係が削除されていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c11f87b1a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=876fa84a2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a19edb66a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3a35ab1d0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c6f369e58">&#167;</a></small></p>
<li>外部キー制約のトリガーに対する遅延実行指定が効かなくなる問題が修正されました。  (Yasuo Honda) (18)</li>
<p>
以前は「DEFERRABLE INITIALLY DEFERRED」として定義された外部キー制約が、「NOT ENFORCED」ステータスに設定された後、再び「ENFORCED」に戻されると「NOT DEFERRABLE」として動作していました。
</p>
<p>
この問題が発生している外部キー制約がある場合は、本マイナーバージョンアップ適用後に「ALTER TABLE ..」で再度「NOT ENFORCED」に設定してから「ENFORCED」に戻すことで修復できます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5db5e3396">&#167;</a></small></p>
<li>ドメインを許可するように「WITHOUT OVERLAPS」が修正されました。  (Jian He) (18)</li>
<p>
「UNIQUE/PRIMARY KEY ... WITHOUT OVERLAPS」で指定する重複しない列は範囲型またはマルチ範囲型である必要がありますが、そのような型を元にしたドメインも許可する必要がありました。これまでは以下のようなエラーになっていました。
</p>
<pre>
（修正前の動作例）
db1=# CREATE DOMAIN dtsrange AS tsrange CHECK (lower(VALUE) IS NOT NULL);
db1=# CREATE TABLE t30 (id int, tsr dtsrange, PRIMARY KEY (id, tsr WITHOUT OVERLAPS));
ERROR:  column "tsr" in WITHOUT OVERLAPS is not a range or multirange type
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=49f3cb453">&#167;</a></small></p>
<li>マルチ範囲型を介して、複合型が再帰的に自身をメンバーとして含むことが禁止されました。  (Heikki Linnakangas) (18)(17)(16)(15)(14)</li>
<p>
これまでも ALTER TABLE ADD COLUMN や ALTER TYPE ADD ATTRIBUTE の際に、ドメイン、配列、複合型、範囲型を通して自身をメンバーとして含まないことを検査していましたが、マルチ範囲型を経由する場合について見落とされていました。
</p>
<pre>
（誤動作例）
db1=# CREATE TYPE typ31 AS (a int, b int);
db1=# CREATE TYPE typ31range AS RANGE (subtype = typ31);
db1=# ALTER TYPE typ31 ADD ATTRIBUTE c typ31range;
→ 修正前は実行できてしまう
　 修正後は「ERROR:  composite type two_ints cannot be made a member of itself」
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ff8f27d6e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=54343f6f9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=06e304524">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=34ebeb15c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c7a1d5fc6">&#167;</a></small></p>
<li>Datumのイメージ比較が符号拡張の違いに依存しないよう修正されました。  (David Rowley) (18)(17)(16)(15)(14)</li>
<p>
従来は「ERROR:  could not find memoization table entry」といったエラーメッセージが出力されたり、誤った問合せ結果を招いていました。
</p>
<p>
DatumとはSQLの各種データ型の値を格納する汎用的な内部実装上のデータ型です。そのイメージ比較とはビット単位での一致を調べる処理です。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=49315de0c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d29808e35">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1bd90c887">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6b2e091f0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6ce5c310b">&#167;</a></small></p>
<li>ハッシュ化された「IN」/「NOT IN」において、非STRICTな等価演算子を使用した場合の処理が修正されました。  (Chengpeng Yan) (18)(17)(16)(15)(14)</li>
<p>
これまでは、NULLを空文字と等価とする独自の等価演算子を拡張機能で定義している場合などで、NULLを含む検索時にクラッシュや誤った問い合わせ結果を引き起こす可能性がありました。
</p>
<p>
なお、組み込みデータ型の等価演算子はすべてSTRICTであるため、この問題は拡張機能で定義されたデータ型でのみ発生します。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=035c520db">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3fda3e12f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a2a0060d5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=622f8b530">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=109de35b7">&#167;</a></small></p>
<li>to_char()における、ロケール依存の長すぎる数値記号を切り詰められるようになりました。  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
to_char()は、パターン内の各フォーマットコードごとに8バイトを見込んで出力バッファを確保しています。ロケールで指定された通貨記号、桁区切り記号、小数点記号、または符号記号が8バイトを超える場合、理論上はバッファオーバーランが発生する可能性がありました。
</p>
<p>
現実にはそのようなロケールは存在せず、さらに権限のない攻撃者がPostgresSQLサーバ配下に悪意あるロケール定義をインストールするのは現実的ではありませんが、安全性を考慮し、記号が長すぎる場合にはそれを検出し、必要に応じて切り詰めるようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=580e7be88">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c97a28618">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e1e60f148">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f60d25986">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8a6f08c0c">&#167;</a></small></p>
<li>「Ispell」辞書用のaffixファイル解析時に発生し得るバッファオーバーランが防止されました。  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
破損した、あるいは悪意あるaffixファイルによってサーバプロセスがクラッシュする可能性があったため、入力値検証を強化し、異常に長いデータを安全に扱えるよう修正されました。
</p>
<p>
なお、テキスト検索設定ファイルは信頼できるものと想定されているため、これはセキュリティ問題の扱いにはなりませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=00c6e0819">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ea5f0d176">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=42383d32d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0b196d3db">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=21a24d709">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c2bfeb3bb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a5426dbf8">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=17f72e037">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f852c9093">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6cae0c2bd">&#167;</a></small></p>
<li>ウィンドウ集約におけるフレーム開始位置および終了位置の計算で、整数オーバーフローが発生しないよう保護されました。  (Richard Guo) (18)(17)(16)(15)(14)</li>
<p>
ユーザ指定のオフセット値が非常に大きい場合（INT64_MAXに近い値）、予期せぬエラーや誤った問い合わせ結果を引き起こす可能性がありました。開発用ビルドではアサート失敗も報告されました。
</p>
<pre>
（誤動作例）
db1=# CREATE TABLE t36 (i int);
db1=# INSERT INTO t36 SELECT generate_series(1, 1000) g;
db1=# SELECT sum(i) 
        OVER (ROWS BETWEEN 0x7fffffffffffffff FOLLOWING AND 1 FOLLOWING), i FROM t36;
ERROR:  window frame head moved backward
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bfc7dff26">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f8736f8bc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0fe032e6a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4da71fc37">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=305cf0df0">&#167;</a></small></p>
<li>array_agg_array_combine()が、配列のNULLビットマップを正しく結合するよう修正されました。  (Dmytro Astapov) (18)(17)(16)</li>
<p>
array_agg_array_combine() はarray_agg()集約関数の内部実装で使われている関数です。
</p>
<p>
この不具合により、NULLと非NULL要素が混在する入力において、並列化されたarray_agg(anyarray)の計算が失敗し、誤った問い合わせ結果が生じるおそれがありました。このエラーは並列ワーカーの実行タイミングに依存するため、再現性の低い不具合として現れていました。
</p>
<pre>
（並列実行プランのときに誤動作が発生する可能性のある問い合わせ例）
db1=# CREATE TABLE t37 (id int, grpid int, c1 int, c2 int, c3 int);
db1=# INSERT INTO t37 SELECT g, g % 10000, 
        nullif(g % 3, 0), nullif(g % 5, 0), nullif(g % 7, 0)
        FROM generate_series(1, 100000) g;
db1=# SELECT grpid, array_agg(ARRAY[c1, c2, c3]) FROM t37 GROUP BY grpid;
　→ この結果が並列実行プランを無効化したときと一致しない場合がある
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=14bf2c39e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d6c9432cb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bb959269e">&#167;</a></small></p>
<li>sync_file_range()がエラーコード「EINTR」を返した場合に再試行するようになりました。  (DaeMyung Kang) (18)(17)(16)</li>
<p>
これまでは、割り込み発生時のリトライ処理が正しく機能していませんでした。sync_file_range()はファイル書き込みをストレージに反映させるときに使われるLinuxのシステムコールです。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6cb307251">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5499be332">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3b35c10a4">&#167;</a></small></p>
<li>共有システムテーブル（カタログ）に対するpg_stat_reset_single_table_counters()の誤動作が修正されました。  (Chao Li) (18)(17)(16)(15)</li>
<p>
これまでは、共有システムテーブルに対して同関数を実行すると、現在のデータベースの「stat_reset_timestamp」（pg_stat_databaseシステムビューのstats_reset列で報告される値）が誤って更新されていました。
</p>
<pre>
（誤動作例）
db1=# SELECT now(), pg_stat_reset_single_table_counters('pg_authid'::regclass);
              now              | pg_stat_reset_single_table_counters
-------------------------------+-------------------------------------
 2026-05-22 13:07:49.624814+09 |
(1 row)

db1=# SELECT datname, stats_reset FROM pg_stat_database
        WHERE datname = current_database();
 datname |          stats_reset
---------+-------------------------------
 db1     | 2026-05-22 13:07:49.627562+09
(1 row)
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b081c5b07">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a4fefb3e0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c7cdcbd3e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c6d3f0585">&#167;</a></small></p>
<li>並列applyワーカーがidle状態のときにアクティビティ統計を更新するようになりました。  (Zhijie Hou) (18)(17)(16)</li>
<p>
これまでは、直近に完了したトランザクションの統計情報が長時間報告されない場合があり、特にワークロードが軽い環境で顕著でした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=44c8dc280">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=88d7fdcc9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d052f6c7d">&#167;</a></small></p>
<li>集合演算で配列長を推定中するときに、予期せぬエラー「ERROR:  no relation entry for relid 0」が発生することがあり、修正されました。  (Tender Wang) (18)(17)</li>
<p>
UNIONなどの集合演算で、元となる型の異なる配列型を型変換する場合に発生することがありました。
</p>
<pre>
（発生例）
db1=# SELECT null::int[] UNION ALL SELECT null::int[] UNION ALL SELECT null::bigint[];
ERROR:  no relation entry for relid 0
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=13e20d1c9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=93ed18720">&#167;</a></small></p>
<li>pglz_decompress()が破損した入力を受け取った場合にバッファの超過読み取りが発生することがあり、修正されました。  (Andrew Dunstan) (18)(17)(16)(15)(14)</li>
<p>
pglz_decompress()はpglz形式の圧縮データを展開する内部実装関数です。破損した圧縮データによって入力末尾を越えた読み取りが発生する可能性があり、ごくまれにクラッシュを引き起こすおそれがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c3e436b1c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c05c3baf1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e630f65d0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c88ad3a21">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=de32a01e7">&#167;</a></small></p>
<li>インクリメンタルJSONパーサにおいて、入力バッファの境界をまたぐ数値トークンの処理が修正されました。  (Andrew Dunstan) (18)(17)</li>
<p>
JSON数値の文法に反する不正な形式の数値を受け入れてしまう可能性があり、その結果として後の処理でエラー（「ERROR:  invalid input syntax for type json」など）が発生することがありえました。デバッグ用ビルドではアサート失敗を引き起こしました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3e4955630">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2e373785e">&#167;</a></small></p>
<li>インクリメンタルバックアップのリストア時に、リレーションの可視性マップが肥大化することがあり、防止されました。  (Robert Haas) (18)(17)</li>
<p>
このリストア処理では、期待されるファイル長の計算が誤っていたため、可視性マップに多数のゼロブロックが追加される可能性がありました。これはデータ破損にはつながりませんが、大量のディスク領域を無用に消費する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9540c0e5d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=076bc57fa">&#167;</a></small></p>
<li>カタログキャッシュのテキスト列検索において、データベースのデフォルト照合順序ではなく、C照合順序が使用されるようになりました。  (Jeff Davis) (18)(17)</li>
<p>
これにより、データベースが特定できずデフォルト照合順序も決定できない特殊ケースでも、物理レプリケーションが開始できるようになります。pg_receivewalによるレプリケーション接続の開始時に「FATAL:  cannot read pg_class without having selected a database」が発生するケースが報告されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=03c4f243e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9dda30dd3">&#167;</a></small></p>
<li>スタンバイサーバ昇格時に、応答待ちのまま停止したslotsyncワーカープロセスが昇格処理をブロックする問題が修正されました。  (Nisha Moond, Ajin Cherian) (18)(17)</li>
<p>
プライマリサーバからの応答を待ち続けていたワーカープロセスにより、昇格処理が不必要に長時間遅延することがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=58c1188a3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=15910b1c3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=acf49bfed">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=586f4266f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=94efd308b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4bed04d39">&#167;</a></small></p>
<li>アイドル状態のslotsyncワーカープロセスによる過剰なログ出力が修正されました。  (Zhijie Hou) (18)(17)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=540fe8fb5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=91741b7cb">&#167;</a></small></p>
<li>tuplestoreデータ構造で、エラー発生後に内部状態の不整合が生じないようになりました。  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
通常は問題になりませんが、WITH HOLDカーソルのtuplestoreでは問題となる可能性がありました。PostgreSQL 15以前では、この問題により容易に再現可能なクラッシュが発生することがありました。PostgreSQL 16以降での影響は確認されていませんが、すべてのサポートバージョンで内部状態の整合性が保たれるよう修正されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=adb7873bb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1f5b6a5e5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=59c139d53">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=811f3263a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7cd23aad2">&#167;</a></small></p>
<li>pg_aiosシステムビューのpid列が、所有プロセスが存在しない場合に0ではなくNULLを示すようになりました。  (ChangAo Chen) (18)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=882bdcf9f">&#167;</a></small></p>
<li>pg_stat_replicationのlag列が実際より早い段階でNULLと報告されてしまう問題が修正されました。  (Shinya Kato) (18)(17)(16)(15)(14)</li>
<p>
特に論理レプリケーション環境で、レプリケーション処理中であるにもかかわらず、過度に早くNULLとなることがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=98e96e579">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fdce5de55">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f42105001">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=246c296f0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bf7ecf353">&#167;</a></small></p>
<li>並列Btreeインデックススキャンで使用される共有メモリの割り当て不足が修正されました。  (Siddharth Kothari) (18)</li>
<p>
稀なケースで、この共有メモリの割り当て不足によりサーバがクラッシュする可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1e71970d2">&#167;</a></small></p>
<li>WAL出力無しのGiSTインデックスを使用する際に、稀に発生するフラッシュ失敗を回避するようになりました。  (Tomas Vondra) (18)(17)(16)(15)(14)</li>
<p>
WAL出力無しのGiSTインデックスにおいて、挿入ポイントを表す擬似LSNの選択が不適切であったため、誤って「ERROR: xlog flush request n/nnnn is not satisfied」が発生することがありました。（なお、ここでのWAL出力無しはUNLOGGEDテーブルを意味していません。）
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5b3f63a1b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6ef36bb35">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4f4025eac">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ce06b5740">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c0ffc725f">&#167;</a></small></p>
<li>変則的なサイズのセグメント使用時に、DSAページマップの必要サイズの過小評価が修正されました  (Paul Bunn) (18)(17)(16)(15)(14)</li>
<p>
この計算ミスにより、範囲外アクセスが発生し、サーバがクラッシュする可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a0f38604d">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2543b9ea9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0af5e64e9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=46c93b705">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=eb11d7a91">&#167;</a></small></p>
<li>共有メモリ内における最も古いマルチトランザクション配列のインデックス計算が修正されました。  (Yura Sokolov) (18)(17)</li>
<p>
PREPARED状態であるが、未コミットのトランザクションが保持する行ロックが他セッションから見えなくなるなど、可視性の不整合が発生する可能性がありました。また、max_connectionsが非常に小さい場合には、メモリ破壊が発生する可能性もありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0a50ef094">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=dcd9c06a4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fa3b328e6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=969576dab">&#167;</a></small></p>
<li>多数のEXPLAIN拡張オプションを登録した場合に発生する配列オーバーランが修正されました。  (Joel Jacobson) (18)</li>
<p>
この問題により、メモリ破損やサーバプロセスのクラッシュが発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=730c98d03">&#167;</a></small></p>
<li>拡張データ型の式に対する拡張統計情報処理時にクラッシュが発生する可能性があり、修正されました。  (Michael Paquier) (18)(17)(16)(15)(14)</li>
<p>
データ型のtypanalyze関数が有効な統計情報を生成しない場合、NULLポインタ参照が発生する可能性がありました。PostgreSQL本体のtypanalyzeでは発生しませんが、拡張機能では発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=83671c0da">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=530b6b02f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=04745ba9c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f033abc6c">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=038c7d4a3">&#167;</a></small></p>
<li>GROUP BY句で使用される結合エイリアス変数を正しく表示するよう修正されました。  (Tom Lane) (18)</li>
<p>
「SELECT ... t1 LEFT JOIN t2 USING (x) GROUP BY x」のようなクエリを含むビューにおいて、GROUP BY句のSQL文が内部からの逆解析時に誤って表示され、データベースのダンプ/リストアが失敗する可能性がありました。この問題は、「t1.x」と「t2.x」のデータ型が同一ではなく、「t1.x」側で暗黙的な型変換が必要だった場合にのみ発生しました。
</p>
<pre>
（誤動作例）
db1=# CREATE TABLE t1 (x integer, a numeric);
db1=# CREATE TABLE t2 (x bigint, b text);
db1=# CREATE VIEW test_view AS SELECT x::integer AS x FROM t1 LEFT JOIN t2 USING (x) GROUP BY x;
（18.3以前では、以下のように誤ったSQLへ逆解析される）
db1=# SELECT pg_get_viewdef('test_view'::regclass, true);
       pg_get_viewdef
-----------------------------
  SELECT t1.x::integer AS x +
    FROM t1                 +
      LEFT JOIN t2 USING (x)+
   GROUP BY (t1.x::bigint);
(1 row)

（この状態でダンプしリストアすると、以下のようなエラーが発生する）
$ pg_dump db1 > dump.sql
$ psql restore_test < dump.sql
ERROR:  column "t1.x" must appear in the GROUP BY clause or be used in an aggregate function
LINE 2:  SELECT (t1.x)::integer AS x
</pre>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c2c1962a6">&#167;</a></small></p>
<li>ICUを使用した文字列処理における、軽微なメモリリークが修正されました。  (Jeff Davis) (18)(17)(16)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4abf63c62">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4761f2eee">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a4515c9b4">&#167;</a></small></p>
<li>startupプロセス失敗時に、他の子プロセスを適切にシャットダウンするよう修正されました。  (Ayush Tiwari) (18)(17)(16)(15)</li>
<p>
従来は「startupプロセス実行中は他のpostmaster子プロセスは存在しない」という古い前提に依存しており、postmasterの即時終了でも問題ないとされていました。残存した子プロセスも最終的にはpostmasterの終了を検知して自主的に終了しますが、より適切なシャットダウン手順が望まれていました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=affdb2dd5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e381843cf">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2d347f2cd">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=23cebf672">&#167;</a></small></p>
<li>チェックポイントのWALリプレイ処理とマルチトランザクションID生成の間に存在する競合状態が修正されました。  (Heikki Linnakangas) (18)(17)(16)(15)(14)</li>
<p>
古いマイナーバージョンのプライマリからWALを追従するスタンバイサーバにおいて、「ERROR: could not access status of transaction」というエラーを伴うクラッシュおよび再起動ループが発生する可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0852643e1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1ca385032">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=77dff5d93">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a5f412107">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e35e466f6">&#167;</a></small></p>
<li>walsenderプロセス終了時に無限待機状態となりうる不具合が修正されました。  (Anthonin Bonnefoy) (18)(17)(16)(15)(14)</li>
<p>
論理レプリケーションのパブリッシャ側のPostgreSQLを停止する際に、walsenderプロセスは未書き込みのWALがすべて書き出されるまで待機します。しかし、その書き出し要求が正しく行われていなかったため、状況によっては待機が終了せず、無限に停止処理が続く場合がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3eb2fecdb">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bbbc0888b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=82935467a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=42734f296">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3bf6f22ce">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=980498138">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8ee536c89">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=da21ecf57">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fa9f2e317">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f15471464">&#167;</a></small></p>
<li>リカバリ中にテーブルの空き領域マップ（FSM）の変更内容が確実に保持されるように修正されました。  (Alexey Makhmutov) (18)(17)(16)(15)(14)</li>
<p>
これまでは、WALリプレイ時にFSMの更新自体は行われていたものの、チェックサムが有効な場合に、FSMページのバッファがダーティページとして印付けされていませんでした。そのため、変更内容がディスクへ書き出されず、反映されない場合がありました。
</p>
<p>
スタンバイサーバでは、この問題により時間の経過とともにFSMの内容が実際のテーブル状態と大きく乖離することがありました。FSMはあくまでヒント情報として使用されるだけですが、スタンバイサーバがアクティブに昇格した際、FSMの大部分が更新によって修復されるまでの間、大きく性能低下するおそれがありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ac3b97db3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1cf010f21">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=54537de35">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ca259b084">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f5d1038d9">&#167;</a></small></p>
<li>ecpgプリプロセッサで、接続が確立されていない状態で一部の関数を呼び出した場合に、クラッシュする不具合が修正されました。  (Shruthi Gowda) (18)(17)(16)(15)(14)</li>
<p>
ECPGdeallocate_all()、ECPGprepared_statement()、ECPGget_desc()、および、ecpg_freeStmtCacheEntry()でセグメンテーション違反が生じました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e2688ea5e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5d67549d9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=7e4c871f4">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6916f4410">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f0e3f9732">&#167;</a></small></p>
<li>pg_basebackupおよびpg_verifybackupでtarファイルの読み込み処理が強化されました。  (Tom Lane) (18)</li>
<p>
これまでは、入力ファイルがtarファイルであるかどうか、さらにPostgreSQLが処理可能なtar形式かどうかの検証が十分に行われていませんでした。そのため、PostgreSQLではない他のtar作成ツールによって生成されたtarファイルを入力とした場合、想定外の形式であることで問題が生じる可能性がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=698eae7db">&#167;</a></small></p>
<li>pg_basebackupおよびpg_verifybackupでバックアップの展開およびtar読み込み処理における各種バグが修正されました。  (Andrew Dunstan, Tom Lane, Chao Li) (18)(17)(16)(15)</li>
<p>
具体的には、tarファイルのパディング領域の扱いの不備、特殊ケースにおいてLZ4圧縮データが破損する可能性、一部の異常系エラー条件の検査漏れ、圧縮／展開のエラー発生後に終了しないことによる連鎖的なエラー報告、メモリリークの発生、ということが含まれます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=5095f3f4a">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f1298a4c2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1590723f0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d3bb7841b">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a01a592b1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8b198b093">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=cce939c71">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=9a42888a3">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=78dc9a808">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2640c5ba7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=415cc943f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4548e8746">&#167;</a></small></p>
<li>pg_dumpにおいて、NOT NULL制約のNO INHERIT属性が正しく保持されるように修正されました。  (Jian He) (18)</li>
<p>
これまでは、一部のケースでNO INHERIT句がダンプ出力されませんでした。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c3c8b63d7">&#167;</a></small></p>
<li>pg_dumpallにおいて、OIDが存在しないロールが権限を与えた場合にもGRANT文を出力するように、修正されました。  (Tom Lane) (18)(17)(16)</li>
<p>
これまでは、このような状態のGRANTがダンプ対象から除外される場合がありました。今回の修正で、PostgreSQL v16より前と同様に、GRANTED BY句を付けずにGRANT文を出力するよう変更されました。
</p>
<p>
なお、権限を与えたロールのOIDが存在しないことに対する警告メッセージは引き続き出力されますが、警告を出すのはソースサーバがPostgreSQL v16以降の場合のみに限定されます。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b09158cc7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1cd783d20">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a4649c50a">&#167;</a></small></p>
<li>pg_upgradeにおいて、古いソースサーバへ接続する際に正しいプロトコルバージョンを使用するように修正されました。  (Jacob Champion) (18)(17)(16)(15)(14)</li>
<p>
これまでは、2018年2月のマイナーリリース（10.2、9.6.7、9.5.11、9.4.16、9.3.21）よりも古いPostgreSQLサーバからアップグレードを行う場合に、不具合が発生する可能性がありました。
</p>
<p>
「FATAL: unsupported frontend protocol ...」が発生するケースが報告されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1b2773179">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=ad7fc3f1f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a38ed212f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e726620d2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c47744ede">&#167;</a></small></p>
<li>contrib/basic_archiveが、起動時にアーカイブディレクトリが存在しなくてもよくなりました。  (Nathan Bossart) (18)(17)(16)(15)</li>
<p>
これまでは、起動時点でbasic_archive.archive_directoryに指定したディレクトリが存在しない場合、その設定自体が無効なものとして扱われました。今回の修正により、起動時点でディレクトリが存在しなくても、後からディレクトリが作成された場合にアーカイブ処理を継続できるようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=bde9ad315">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=f510577de">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=28c2b7896">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8fc45ac5d">&#167;</a></small></p>
<li>contrib/ltreeが、大文字小文字のフォールドで文字列のバイト長が変化する場合に対応できるように修正されました。  (Jeff Davis) (18)(17)(16)(15)(14)</li>
<p>
これまでは、大文字小文字を区別しないマッチングを指定するlqueryパターンにおいて、本来一致するはずのラベルにマッチしない場合がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=b3c2a3d38">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=53a57cae1">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=d1bd9a7dc">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=3ed2c7ef7">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=2b993167f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=058710d41">&#167;</a></small></p>
<li>contrib/pg_overexplainにおいて、RANGE_TABLEオプションの出力構造の不具合が修正されました。  (Satyanarayana Narlapuram) (18)</li>
<p>
これまでは、JSON、YAML、XML形式の出力で一部のフィールドが誤った位置に出力される場合がありました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=6723d462d">&#167;</a></small></p>
<li>contrib/pg_stat_statementsで、pgss_query_texts.statファイルの解析中にエラーが発生した時に、メモリリークが発生しないように修正されました。  (Heikki Linnakangas) (18)(17)(16)(15)(14)</li>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=25b02320e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=351e59f34">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=52edaf9d9">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=92cf11171">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=a6d03067f">&#167;</a></small></p>
<li>contrib/postgres_fdwにおいて、利用不能になった接続を早期に解放してしまうことでクラッシュすることがあり、修正されました。  (Etsuro Fujita) (18)(17)(16)(15)(14)</li>
<p>
オープン中のカーソルなどのデータ構造に接続オブジェクトへの参照が残っている可能性があるため、トランザクション終了まで接続オブジェクトのクローズを遅延させるようになりました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=c318777da">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=af8f9248f">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=1352651c2">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=34c18a225">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=fd5b36ab1">&#167;</a></small></p>
<li>タイムゾーンデータファイルがtzdata release 2026bに更新されました。  (Tom Lane) (18)(17)(16)(15)(14)</li>
<p>
ブリティッシュコロンビア州（America/Vancouver）は、2026年11月から通年でUTC-07を使用するようになります（事実上の恒久的な夏時間）。同地域のタイムゾーン略称がそれ以降「MST」になると想定しています。実際には別の略称へ変更される可能性もありますが、現時点では未確定です。
</p>
<p>
モルドバの歴史的変更も行なわれました。モルドバは2022年以降、EUの夏時間切替時刻に従っていたことが反映されました。
</p>
<p><small> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=8a431b6d6">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=4c0eab6f0">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=0465c999e">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=e28fc73d5">&#167;</a> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;h=affd929c9">&#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>
	</channel>
</rss>
