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

<channel>
	<title>PostgreSQL 11.22 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql-11-22/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>Wed, 04 Nov 2026 06:45:07 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.3</generator>

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

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

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

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