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

<channel>
	<title>PostgreSQL 13.12 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql-13-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>Thu, 15 Oct 2026 03:38:35 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.3</generator>

<image>
	<url>https://www.sraoss.co.jp/tech-blog/wp-content/uploads/2018/07/blog-icon-150x150.png</url>
	<title>PostgreSQL 13.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 13.13 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/13-13/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Mon, 27 Nov 2023 00:30:10 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 13]]></category>
		<category><![CDATA[PostgreSQL 13.12]]></category>
		<category><![CDATA[PostgreSQL 13.13]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=13329</guid>

					<description><![CDATA[このリリースは 13.12 からの修正リリース（2023年 11月 9日リリース）です。 13.X からのアップデートではダンプ、リストアは不要です。 しかしながら、いくつかの修正を適用するにはインデックス再構築が必要で ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 13.12 からの修正リリース（2023年 11月 9日リリース）です。<br />
13.X からのアップデートではダンプ、リストアは不要です。</p>
<p>しかしながら、いくつかの修正を適用するにはインデックス再構築が必要です。項目4番、5番、6番、7番について確認してください。<br />
また、13.12 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/13-12/ ">13.12 のリリース情報</a>も参照してください。</p>
<p><span id="more-13329"></span></p>
<h3>PostgreSQL 14.9 から 14.10 への変更点</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 13.12 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/13-12/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Wed, 16 Aug 2023 23:55:38 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 13]]></category>
		<category><![CDATA[PostgreSQL 13.11]]></category>
		<category><![CDATA[PostgreSQL 13.12]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=12928</guid>

					<description><![CDATA[このリリースは 13.11 からの修正リリース（2023年 8月 10日リリース）です。 13.X からのアップデートではダンプ、リストアは不要です。 しかしながら、NULL値を含む列に BRINインデックスを使っている ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 13.11 からの修正リリース（2023年 8月 10日リリース）です。<br />
13.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、NULL値を含む列に BRINインデックスを使っている場合には、インデックスを再構築することを推奨します。<br />
また、13.7 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/13-7/ ">13.7 のリリース情報</a>も参照してください。</p>
<p><span id="more-12928"></span></p>
<h3>PostgreSQL 13.11 から 13.12 への変更点</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>
	</channel>
</rss>
