<?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 12 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql-12/feed/index.xml" rel="self" type="application/rss+xml" />
	<link>https://www.sraoss.co.jp/tech-blog/</link>
	<description>OSS専門の技術ブログ。PostgreSQL、Zabbixを中心に10種類以上のOSSの解説、アップデート情報、運用ヒントを提供。</description>
	<lastBuildDate>Fri, 23 Oct 2026 06:50:17 +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 12 &#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 12.22 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/12-22/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Wed, 18 Dec 2024 05:17:12 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 12]]></category>
		<category><![CDATA[PostgreSQL 12.21]]></category>
		<category><![CDATA[PostgreSQL 12.22]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=15898</guid>

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

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

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 12.21 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/12-21/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Wed, 18 Dec 2024 05:10:18 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 12]]></category>
		<category><![CDATA[PostgreSQL 12.20]]></category>
		<category><![CDATA[PostgreSQL 12.21]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=15884</guid>

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

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

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 12.20 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/12-20/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Thu, 29 Aug 2024 00:10:48 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 12]]></category>
		<category><![CDATA[PostgreSQL 12.19]]></category>
		<category><![CDATA[PostgreSQL 12.20]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=15027</guid>

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

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

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 12.19 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/12-19/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Fri, 24 May 2024 02:36:42 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 12]]></category>
		<category><![CDATA[PostgreSQL 12.18]]></category>
		<category><![CDATA[PostgreSQL 12.19]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=14664</guid>

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

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

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 12.18 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/12-18/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Tue, 27 Feb 2024 00:00:45 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 12]]></category>
		<category><![CDATA[PostgreSQL 12.17]]></category>
		<category><![CDATA[PostgreSQL 12.18]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=14423</guid>

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

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

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 12.17 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/12-17/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Mon, 27 Nov 2023 00:15:55 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 12]]></category>
		<category><![CDATA[PostgreSQL 12.16]]></category>
		<category><![CDATA[PostgreSQL 12.17]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=13331</guid>

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

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

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

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

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

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

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

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

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

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

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

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 12.13 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/12-13/</link>
		
		<dc:creator><![CDATA[高塚 遥 (Haruka Takatsuka)]]></dc:creator>
		<pubDate>Thu, 01 Dec 2022 00:30:29 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQ]]></category>
		<category><![CDATA[PostgreSQL 12]]></category>
		<category><![CDATA[PostgreSQL 12.12]]></category>
		<category><![CDATA[PostgreSQL 12.13]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=11845</guid>

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

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

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