<?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 10 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql-10/feed/index.xml" rel="self" type="application/rss+xml" />
	<link>https://www.sraoss.co.jp/tech-blog/</link>
	<description>OSS専門の技術ブログ。PostgreSQL、Zabbixを中心に10種類以上のOSSの解説、アップデート情報、運用ヒントを提供。</description>
	<lastBuildDate>Fri, 23 Oct 2026 06:42:00 +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 10 &#8211; SRA OSS Tech Blog</title>
	<link>https://www.sraoss.co.jp/tech-blog/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>PostgreSQL 10.23 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/10-23/</link>
		
		<dc:creator><![CDATA[高塚 遥 (Haruka Takatsuka)]]></dc:creator>
		<pubDate>Wed, 30 Nov 2022 23:00:36 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQ]]></category>
		<category><![CDATA[PostgreSQL 10]]></category>
		<category><![CDATA[PostgreSQL 10.22]]></category>
		<category><![CDATA[PostgreSQL 10.23]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=11849</guid>

					<description><![CDATA[このリリースは 10.23 からの修正リリース（2022年11月10日リリース）です。 10.X からのアップデートではダンプ、リストアは不要です。 しかしながら、10.19 よりも前のバージョンからアップデートする場合 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 10.23 からの修正リリース（2022年11月10日リリース）です。<br />
10.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、10.19 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/10-19/ ">10.19 のリリース情報</a>も参照してください。<br />
本リリースは 10.X 系列の最終リリースになる見込みです。</p>
<p><span id="more-11849"></span></p>
<h3>PostgreSQL 10.22 から 10.23 への変更点</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>
		<item>
		<title>PostgreSQL 10.22 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/10-22/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Mon, 05 Sep 2022 01:30:17 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 10]]></category>
		<category><![CDATA[PostgreSQL 10.21]]></category>
		<category><![CDATA[PostgreSQL 10.22]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=10958</guid>

					<description><![CDATA[このリリースは 10.21 からの修正リリース（2022年8月11日リリース）です。 10.X からのアップデートではダンプ、リストアは不要です。 しかしながら、10.19 よりも前のバージョンからアップデートする場合に ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 10.21 からの修正リリース（2022年8月11日リリース）です。<br />
10.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、10.19 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/10-19/ ">10.19 のリリース情報</a>も参照してください。</p>
<p><span id="more-10958"></span></p>
<h3>PostgreSQL 10.21 から 10.22 への変更点</h3>
<p>14.5、13.8、12.12、11.17、10.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>拡張のスクリプトが、拡張に属していないオブジェクトを置換しないようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
この変更は、拡張に属さない既存オブジェクトがある場合に、拡張のスクリプトが CREATE OR REPLACE を行うことを防止します。また、同じ状況での CREATE IF NOT EXISTS も防止します。 これにより、敵対的なデータベースユーザが拡張のオブジェクトの所有者になって、それを変更して将来の他ユーザによるオブジェクト使用を危機にさらすという、トロイの木馬型の攻撃を防ぐことができます。 副次的な利点として、意図しないオブジェクトを誤って置換してしまうリスクも軽減されます。(CVE-2022-2625)
</p>
<li>スタンバイサーバでの「CREATE DATABASE」WALレコードのリプレイが修正されました。  (Kyotaro Horiguchi, Asim R Praveen, Paul Guo) (14)(13)(12)(11)(10)</li>
<p>
スタンバイサーバがデータベース作成の WALレコードをリプレイする時に、テーブルスペースのディレクトリが見つからないことがあります。 本パッチ適用前は、このような場合、スタンバイはリカバリに失敗していましたが、このようなディレクトリが合法的に欠落している可能性がありました。テーブルスペースを（通常のディレクトリとして）作成し、リプレイが一貫した状態に達したら、再び削除されていることを確認する動作に変更されました。
</p>
<li>「構内」テーブルスペースがサポートされました。  (Thomas Munro, Michael Paquier, &Aacute;lvaro Herrera) (14)(13)(12)(11)(10)</li>
<p>
通常、PostgreSQL のテーブルスペースは、他のファイルシステム上のディレクトリへのシンボリックリンクですが、この変更により、データベースクラスタディレクトリ内の単なるディレクトリにすることができます。
</p>
<p>
これはテストには便利な仕組みです。さらに、CREATE DATABASE リプレイの修正（前項の修正）で、欠落しているテーブルスペースを構内テーブルスペースとして一時的に作成するために必要となります。
</p>
<p>
設定パラメータ allow_in_place_tablespaces が追加されています。以下のように使用できます。
</p>
<pre>
（以下を実行すると pg_tblspc 以下にテーブルスペース用ディレクトリが作られる）
db1=# SET allow_in_place_tablespaces TO on;
db1=# CREATE TABLESPACE sp1 LOCATION '';
CREATE TABLESPACE
</pre>
<li>CREATE INDEX における権限チェックが修正されました。  (Nathan Bossart, Noah Misch) (14)(13)(12)(11)(10)</li>
<p>
CVE-2022-1552 むけの修正により、CREATE INDEX が演算子クラスやその他のオブジェクトの検索を実行する際に、以前は呼び出しユーザのパーミッションを適用していたところで、テーブル所有者のパーミッションを適用するようになっていました。pg_dump はパーミッションを再度付与する前に CREATE INDEX を発行するため、これによりダンプ/リストアのシナリオが壊れていました。
</p>
<p>
本修正で問題を回避するように調整されました。
</p>
<li>拡張問い合わせプロトコルでは、トランザクションブロック内で実行できないCREATE DATABASE 等のコマンド後に、即時コミットを強制するようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
クライアントがそのようなコマンドの直後に Sync メッセージを送信せず、代わりに別のコマンドを送信した場合、そのコマンドで障害が発生すると、直前のコマンドがロールバックされ、通常ディスク上に矛盾した状態が残りました（欠落しているデータベースディレクトリや余分なデータベースディレクトリなど）。
</p>
<p>
そのような状況を防ぐためのメカニズムは、簡易問い合わせメッセージ内の複数コマンドに対しては機能しますが、拡張問い合わせの一連のメッセージに対しては機能しません。現在動作しているユースケースを壊さずに矛盾を防ぐため、そのようなコマンドの後に暗黙のコミットを強制するものとなりました。
</p>
<li>トランザクションの可視性をチェックする際の競合状態が修正されました。  (Simon Riggs) (14)(13)(12)(11)(10)</li>
<p>
内部実装関数 TransactionIdIsInProgress(xid) が、対象のトランザクションが可視とみなされる前に「false」を報告し、さまざまな誤動作を引き起こす可能性がありました。競合状態のウィンドウは通常、非常に狭いですが、同期レプリケーションを使用すると同期レプリカの待機がそのウィンドウ内で発生するため、より広くなります。
</p>
<p>
代表的な誤動作は以下のエラーが出ることです。
</p>
<pre>
ERROR:  t_xmin is uncommitted in tuple to be updated
</pre>
<li>最上位以外に集合を返す関数を含む式でソートした場合の誤った計画が修正されました。  (Richard Guo, Tom Lane) (14)(13)</li>
<p>
以下ような形状の問い合わせについて、予期せぬエラー「ERROR:  set-valued function called in context that cannot accept a set」が生じるケースが報告されました。
</p>
<pre>
SELECT unnest(ARRAY[]::integer[]) + 1 AS pathkey
  FROM ta JOIN tb ON ta.c1 = tb.c1 ORDER BY pathkey
</pre>
<li>拡張統計情報の誤った権限検査コードが修正されました。  (Richard Guo) (14)</li>
<p>
ユーザが不十分な SELECT権限しか持たないテーブルに拡張統計情報がある場合、一部の問い合わせが「ERROR:  permission denied ...」ではなく、「ERROR:  unrecognized node type」で失敗していました。
</p>
<li>ブール値式の MCV（最頻値）型の統計情報を処理するために、拡張統計情報の仕組みが修正されました。  (Tom Lane) (14)</li>
<p>
統計収集は正常に動作しますが、WHERE にその式を含む問い合わせは、プラン作成時に「ERROR:  unknown clause type ...」で失敗していました。
</p>
<pre>
（エラー発生例）
db=# CREATE TABLE t9 (a int, b int);
db=# CREATE STATISTICS stat_ex1 ON
       (CASE a WHEN 1 THEN true ELSE false END), b FROM t9;
db=# INSERT INTO t9 SELECT g % 10, g FROM generate_series(1,10000) g;
db=# ANALYZE t9;
db=# SELECT * FROM t9 WHERE (CASE a WHEN 1 THEN true ELSE false END) AND b = 2;

ERROR:  unknown clause type: 134
</pre>
<li>配列変数に MCV（最頻値）タイプの拡張統計情報がある場合に「constant = ANY(array)」句に対してプランナでクラッシュが生じていて、修正されました。  (Tom Lane) (14)(13)</li>
<pre>
（障害発生例）
db=# CREATE TABLE t10 (c int, a int[]);
db=# CREATE STATISTICS stat_ex10 (mcv) ON c, a FROM t10;
db=# INSERT INTO t10 SELECT g, ARRAY[g] FROM generate_series(1, 10) g;
db=# ANALYZE t1
db=# SELECT * FROM t10 WHERE c = ANY (ARRAY[1,2,3]) AND 1 = ANY(a);

server closed the connection unexpectedly
</pre>
<li>「ALTER TABLE ... ENABLE/DISABLE TRIGGER」がパーティションテーブル上のトリガの再帰を正しく処理するように修正されました。  (&Aacute;lvaro Herrera, Amit Langote) (14)(13)(12)(11)</li>
<p>
場合によっては、コマンドがトリガを持たない子パーティションでトリガを調整しようとするため、「ERROR:  trigger does not exist」が発生することがありました。
</p>
<li>拡張統計情報の計算中に ANALYZE をキャンセルできるようになりました。  (Tom Lane, Justin Pryzby) (14)</li>
<p>
高コストな統計情報対象を伴うシナリオでは、キャンセルできないソート操作に何秒も費やす可能性がありました。
</p>
<li>jsonpath型の構文エラーメッセージが改善されました。  (Andrew Dunstan) (14)(13)(12)</li>
<p>
「ERROR:  syntax error, unexpected IDENT_P at or near " " of jsonpath input」のような、パーサ実装のトークン名を伴うメッセージが出ていました。
</p>
<li>pg_stop_backup() がセッションの状態を適切にクリーンアップするようになりました。  (Fujii Masao) (14)(13)(12)(11)(10)</li>
<p>
これまで省略されていたため、セッションの後半でアサート失敗やクラッシュを引き起こす可能性がありました。
</p>
<li>ゼロ次元の配列の引数を適切に処理するように trim_array() が修正されました。  (Martin Kalcher) (14)</li>
<p>
不正メモリアクセスにより、潜在的にクラッシュが生じる可能性がありました。
</p>
<li>「FOR [KEY] UPDATE/SHARE」句における結合エイリアスのマッチングが修正されました。  (Dean Rasheed) (14)(13)(12)(11)(10)</li>
<p>
稀なケースでは、誤解を招くエラーが報告されることがありました。
</p>
<p>
「ERROR:  FOR UPDATE cannot be applied to a join」とするべきところで、「ERROR:  relation "..." in FOR UPDATE clause not found in FROM clause」が出力される動作が報告されました。
</p>
<li>多すぎる列を持つ FROM の中の ROW() 表現と関数を拒絶するようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
おおよそ 1600列を超えるケースはサポートされておらず、必ず実行に失敗します。しかしながら、32K を超える列を持った問い合わせによって、アサート失敗またはクラッシュが発生する以前のコードが一部ありました。これを避けるために構文解析するときに検査するようになりました。
</p>
<li>ビューが作られて複合型の列がドロップされた場合、複合型を返す FROM の中の関数を使っているビューのダンプが修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
ダンプされたビューはこの関数に対する過剰な列エイリアスを持っているため、ダンプ／リストアや pg_upgrade でのエラーを引き起こしました。
</p>
<pre>
（障害動作例）
db=# CREATE TYPE typ18 AS (c1 int, c2 int, c3 int);
db=# CREATE VIEW v18 AS SELECT * FROM fn18();
db=# ALTER TYPE typ18 DROP ATTRIBUTE c2;
db=# SELECT pg_get_viewdef('v18', true); -- ダンプ時の出力を確認
          pg_get_viewdef
----------------------------------
  SELECT fn18.c1,                +
     fn18.c2,                    +
     fn18.c3                     +
    FROM fn18() fn18(c1, c2, c3);
(1 row)
db=# SELECT fn18.c1, fn18.c2, fn18.c3 FROM fn18() fn18(c1, c2, c3);
ERROR:  table "fn18" has 2 columns available but 3 columns specified
</pre>
<li>論理レプリケーションの walsender で、同セッション内からの入れ子のベースバックアップ取得処理を禁止するようになりました。  (Fujii Masao) (14)(13)(12)(11)(10)</li>
<p>
クラッシュやアサート失敗を起こす可能性がありました。
</p>
<li>論理レプリケーションのサブスクライバのメモリリークが修正されました。  (Hou Zhijie) (14)(13)(12)(11)(10)</li>
<li>ターゲットテーブルがパーテション化されている場合、論理レプリケーションのレプリカアイデンティティ（REPLICA IDENTITY）の検査が修正されました。  (Shi Yu, Hou Zhijie) (14)(13)</li>
<p>
子パーティションについてのレプリカアイデンティティ列の検査が抜け落ちていました。
</p>
<p>
サブスクライバ側でアサート失敗を引き起こす動作が報告されました。
</p>
<li>論理レプリケーションにおいてパブリッシャのスキーマを変更した後にサブスクライバでキャッシュされたスキーマデータの更新に失敗していて、これが修正されました。  (Shi Yu, Hou Zhijie) (14)(13)</li>
<li>「BRIN_EVACUATE_PAGE」フラグを正しく処理するように、WAL一貫性の検査ロジックが修正されました。  (Haiyang Wang) (14)(13)(12)(11)(10)</li>
<li>共有ハッシュテーブル管理における誤ったアサート検査が修正されました。  (Thomas Munro) (14)(13)(12)(11)</li>
<li>min_dynamic_shared_memory がデフォルトでない値にセットされた時に起きるアサート失敗が回避されました。  (Thomas Munro) (14)</li>
<li>SPI_commit() のなかでコミット時のエラーが起きた時、呼び出し元がクリーンアップしてくれることを期待せずに自動で行うようになりました。  (Peter Eisentraut, Tom Lane) (14)(13)(12)(11)</li>
<p>
適切なクリーンアップには複雑で低レベルな機能を必要とします。従って、どの既知の呼び出し元もクリーンアップしないことがあり得ます。このために、手続き言語が COMMIT を発行したが（例えば遅延制約検査などで）エラーが起きてしまった場合に誤動作を招きます。
</p>
<p>
これを改善するために SPI_commit() を次のように再定義しました。即ち、前トランザクションの特性を保存せずに新しいデフォルトトランザクションの特性を取ること以外は、SPI_commit_and_chain() と等価な新しいトランザクションを開始するものとしました。この変更を透過的にするため、SPI_start_transaction() を no-op（何もしない動作）に再定義しました。全ての SPI_commit() の既知の呼び出し元は直後に SPI_start_transaction() を呼びます。これにより全ての呼び出し元は本変更の影響を受けません。同じ変更は SPI_rollback() にも行われています。
</p>
<p>
PL/Python の修正も行われました。PL/Python では、このようなエラー処理が完全に省略されていて、Python 3.11 ではクラッシュすると報告されており、古いバージョンでは何も問題ないように見えますがメモリリークが起きます。
</p>
<li>パイプラインモードでの libpq のアイドル状態の処理が改善されました。  (&Aacute;lvaro Herrera, Kyotaro Horiguchi) (14)</li>
<p>
時々「WARNING:  message type 0x33 arrived from server while idle」が出る動作が報告されていました。また、PQgetResult() から問い合わせの最後の NULL の結果が失われる可能性がありました。
</p>
<li>ecpglib で予想外の順序の操作でのクラッシュが回避されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
EXEC SQL PREPARE などの特定の操作をデータベース接続を確立する前に呼び出すと、エラーを報告するのではなくクラッシュしました。
</p>
<li>ecpglib で冗長な newlocale() 呼び出しが回避されました。  (Noah Misch) (14)(13)(12)(11)(10)</li>
<p>
クエリごとにロケールオブジェクトを作成して解放するのではなく、最初の接続時にプロセスごとに C ロケールオブジェクトを割り当てるように修正されました。これにより、AIX における libc の メモリリークが軽減され、また、どのプラットフォームでも性能向上が見込まれます。
</p>
<li>psql の \watch コマンドで、Ctrl-C でキャンセルした後に改行をエコーするようになりました。  (Pavel Stehule) (14)(13)(12)(11)(10)</li>
<p>
これにより、libedit (およびおそらく libreadline) でカーソルがどの列にあるかについて混乱するのを防ぎます。
</p>
<pre>
（動作例）
db=# SELECT 1;
 ?column?
----------
        1
(1 row)

db=# \watch
2022年08月16日 07時53分10秒 (every 2s)

 ?column?
----------
        1
(1 row)

（修正前の動作）
^Cdb=#

（修正後の動作）
^C
db=#
</pre>
<li>pg_upgrade がアップグレード不可能な anyarray を取る関数を検出するように修正されました。  (Justin Pryzby) (14)</li>
<p>
バージョン 14 では、いくつかの組み込み関数が、anyarray ではなく anycompatiblearray 型を取るように変更されました。これはほとんど透過的ですが、これらの関数の上に構築されたユーザ定義の集約関数と演算子は、正確に一致する型で宣言する必要があります。古いシグネチャを参照するオブジェクトが存在すると、pg_upgrade が失敗する原因となるため、アップグレードを開始する前に、そのようなケースを検出して報告するように変更されました。
</p>
<pre>
(修正後の動作)
$ pg_upgrade -b /usr/local/pgsql-13.8/bin -B /usr/local/pgsql-14.5/bin \
    -d /usr/local/pgsql-13.8/data -D /usr/local/pgsql-14.5/data
Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for user-defined encoding conversions              ok
Checking for user-defined postfix operators                 ok
Checking for incompatible polymorphic functions             fatal

Your installation contains user-defined objects that refer to internal
polymorphic functions with arguments of type "anyarray" or "anyelement".
These user-defined objects must be dropped before upgrading and restored
afterwards, changing them to refer to the new corresponding functions with
arguments of type "anycompatiblearray" and "anycompatible".
A list of the problematic objects is in the file:
    incompatible_polymorphics.txt

Failure, exiting
$ cat incompatible_polymorphics.txt
In database: postgres
  aggregate: public.array_accum(anyelement)
</pre>
<li>pg_upgrade で --clone オプションを使用した場合に、clone() が失敗した後に誤った（OSからの）エラーメッセージが報告される可能性があり、修正されました。  (Justin Pryzby) (14)(13)(12)</li>
<li>contrib/pg_stat_statements が 32 ビットプラットフォームでの巨大な（数ギガバイトの）問い合わせ文字列ファイルでの整数オーバフローを回避するように修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
これに伴って、pg_stat_statements.max の最大値が 2147483647 から 1073741823 に変更されました。
</p>
<li>contrib/postgres_fdw で「WITH CHECK OPTION」制約がある場合に一括挿入を防止するようになりました。  (Etsuro Fujita) (14)</li>
<p>
外部テーブルのビューが WITH CHECK OPTION 制約を持つ場合、リモートで挿入されるデータを取得し、制約をチェックしますが、一度に複数の行が挿入されると、最初の 1行しかリモートのデータを取得できず、残りの行はローカルのデータで制約をチェックしていました。そのため、リモートのテーブルが行単位 BEFORE INSERT トリガをもち、リモートでデータが変更される場合、制約を適切にチェックできませんでした。
</p>
<pre>
db=# CREATE SERVER loopback
       FOREIGN DATA WRAPPER postgres_fdw OPTIONS (dbname 'db');
db=# CREATE USER MAPPING FOR CURRENT_USER SERVER loopback;
db=# CREATE FUNCTION row_before_insupd_trigfunc()
       RETURNS trigger LANGUAGE plpgsql AS $$
         BEGIN NEW.a := NEW.a + 10; RETURN NEW; END; $$;
db=# CREATE TABLE base_tbl (a int, b int);
db=# CREATE TRIGGER row_before_insupd_trigger
       BEFORE INSERT OR UPDATE ON base_tbl FOR EACH ROW
       EXECUTE PROCEDURE row_before_insupd_trigfunc();
db=# CREATE FOREIGN TABLE foreign_tbl (a int, b int)
       SERVER loopback OPTIONS (table_name 'base_tbl');
db=# CREATE VIEW rw_view AS
       SELECT * FROM foreign_tbl WHERE a &lt; b WITH CHECK OPTION;
db=# ALTER SERVER loopback OPTIONS (ADD batch_size '10');

（修正前の動作: Batch Size が 10 のまま、
  2行目の挿入が変更前データでチェックされ、制約違反のデータが格納される）
db=# EXPLAIN (VERBOSE, COSTS OFF) INSERT INTO rw_view VALUES (0, 15), (0, 5);
                                   QUERY PLAN
--------------------------------------------------------------------------------
 Insert on public.foreign_tbl
   Remote SQL: INSERT INTO public.base_tbl(a, b) VALUES ($1, $2) RETURNING a, b
   Batch Size: 10
   -&gt;  Values Scan on "*VALUES*"
         Output: "*VALUES*".column1, "*VALUES*".column2
 Query Identifier: -8082510435137086002
(6 rows)

db=# INSERT INTO rw_view VALUES (0, 15), (0, 5);
INSERT 0 2

（修正後の動作: Batch Size が 1 になり、
  2行目の挿入が変更後のデータでチェックされ、制約違反でエラーになる）
db=# EXPLAIN (VERBOSE, COSTS OFF) INSERT INTO rw_view VALUES (0, 15), (0, 5);
                                   QUERY PLAN
--------------------------------------------------------------------------------
 Insert on public.foreign_tbl
   Remote SQL: INSERT INTO public.base_tbl(a, b) VALUES ($1, $2) RETURNING a, b
   Batch Size: 1
   -&gt;  Values Scan on "*VALUES*"
         Output: "*VALUES*".column1, "*VALUES*".column2
 Query Identifier: 9094516644014608466
(6 rows)

db=# INSERT INTO rw_view VALUES (0, 15), (0, 5);
ERROR:  new row violates check option for view "rw_view"
DETAIL:  Failing row contains (10, 5).
</pre>
<li>contrib/postgres_fdw が非同期データフェッチクエリの送信失敗を検出するように修正されました。  (Fujii Masao) (14)</li>
<li>contrib/postgres_fdw が regconfig およびその他の reg* タイプの定数を適切なスキーマ pg_catalog 修飾で送信するようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<li>Linux で動的共有メモリの割り当て中にシグナルをブロックするようになりました。  (Thomas Munro) (14)(13)(12)(11)(10)</li>
<p>
これにより、シグナルが posix_fallocate() に割り込むときのバスエラー (SIGBUS) が回避されます。
</p>
<li>shm_open() からの予期しない「EEXIST」エラーを検出するようになりました。  (Thomas Munro) (14)(13)(12)(11)(10)</li>
<p>
これにより、Solaris で発生する可能性のあるクラッシュが回避されます。
</p>
<li>オープンソースの Unix 系 OS illumos では signalfd() を使用しないようになりました。  (Thomas Munro) (14)</li>
<p>
これにより、ハングアップやカーネルパニックが発生するように見えるため、修正が利用可能になるまでこの機能は使用されません。
</p>
<li>複合型に対するドメインを返す関数の結果を行全体の変数で参照する問い合わせ処理が修正されました。  (Tom Lane) (13)(12)(11)</li>
<pre>
（修正前のエラー動作例）
db=# CREATE TYPE ctyp4 AS (c1 boolean, c2 boolean);
db=# CREATE DOMAIN dom4 AS ctyp4 NOT NULL;
db=# CREATE FUNCTION f_ctyp4() RETURNS ctyp4 LANGUAGE sql
     AS $$ SELECT (true, true) $$;
db=# CREATE FUNCTION f_dom4() RETURNS dom4 LANGUAGE sql
     AS $$ SELECT (true, true) $$;

（複合型を返す場合は動作する）
db=# SELECT f_ctyp4 FROM f_ctyp4();
 f_ctyp4
------------------------
 (t,t)
(1 row)

（複合型のドメインを返す場合にエラーになっていた - 修正後は動作する）
db1=# SELECT f_dom4 FROM f_dom4();
ERROR:  type dom4 is not composite
</pre>
<li>プランナで GROUPING 関数で参照されている副問い合わせをプルアップする（上位の問い合わせに統合する）ときに、「ERROR: variable not found in subplan target list」が生じる問題が修正されました。  (Richard Guo) (13)(12)(11)(10)</li>
<pre>
（修正前バージョンでのエラー発生例）
db=# CREATE TABLE t5 AS SELECT generate_series(1, 100)::int i ;
db=# SELECT GROUPING(ss.x) FROM t5 CROSS JOIN LATERAL (
       SELECT (SELECT t5.i) as x) ss GROUP BY ss.x;
ERROR:  variable not found in subplan target list
</pre>
<li>pg_stat_get_subscription() 関数がゴミデータを含んだ追加の行を返す可能性があり、防止されました。  (Kuntal Ghosh) (13)(12)(11)(10)</li>
<p>
pg_stat_get_subscription() 関数は pg_stat_subscription ビューから使われます。
</p>
<li>XMLTABLE や JSON_TABLE に多すぎる列別名を付加した場合のクラッシュが回避されました。  (&Aacute;lvaro Herrera) (13)(12)(11)(10)</li>
<p>
そのような問い合わせに適切なエラーを返すようになりました。これまでは奇妙なエラーが出たり、クラッシュしたりしていました。
</p>
<pre>
（修正後の動作、f(v1,v2) で実際の列数より多く別名が指定されている）
db=# SELECT * FROM XMLTABLE (ROW () PASSING null COLUMNS v1 timestamp)
     AS f (v1, v2);
ERROR:  XMLTABLE function has 1 columns available but 2 columns specified

（修正前のエラーメッセージ）
ERROR:  no relation entry for relid 0
</pre>
<li>ビューやルールを（ダンプ出力や psql での表示のため）逆コンパイルする際、それが他で参照されうる場合には、SELECT 出力列の「AS "?column?"」別名句を見せるようになりました。  (Tom Lane) (13)(12)(11)(10)</li>
<p>
これまでは、自動生成されたこの別名は常に隠されていましたが、結果としてビューやルールがリストア不能になる稀なケースがありました。
</p>
<li>暗黙的に作成された演算子族がイベントトリガに通知されるようになりました。  (Masahiko Sawada) (13)(12)(11)(10)</li>
<p>
以前は、CREATE OPERATOR CLASS によって演算子族が暗黙的に作成された場合、イベントトリガに通知されませんでした。
</p>
<li>スタンバイサーバの昇格中にリスタートポイントが実行されている時に行われるコントロールファイルの更新が、修正されました。  (Kyotaro Horiguchi) (13)(12)(11)(10)</li>
<p>
以前は、リスタートポイント完了時にコントロールファイルの最終チェックポイントのフィールドが誤って更新される可能性があり、次の通常チェックポイント完了前にサーバがクラッシュした場合、PANIC が発生して再起動に失敗する可能性がありました。
</p>
<li>大規模トランザクションの論理レプリケーション中に、スタンバイの wal_receiver_timeout を発動させないようになりました。  (Wang Wei, Amit Kapila) (13)(12)(11)(10)</li>
<p>
以前は、プライマリサーバ上の大規模トランザクションが（おそらく変更されたテーブルがパブリッシュされていないために）スタンバイにデータを送信しない場合、スタンバイがタイムアウトする可能性がありました。キープアライブメッセージを定期的に送信することで修正されました。
</p>
<li>無効なタイムゾーン省略形ファイルを読み取る際のファイルクローズ漏れが防止されました。  (Kyotaro Horiguchi) (13)(12)(11)(10)</li>
<p>
このような場合には無害な警告メッセージが生じることがありました。
</p>
<li>カスタムサーバパラメータの短い説明に NULL を指定できるようになりました。  (Steve Chavez) (13)(12)(11)(10)</li>
<p>
短い説明は SHOW ALL の description などに表示されるもので、以前は、拡張でここに NULL を指定していると表示処理がクラッシュしていました。
</p>
<li>libpq で SSL 秘密鍵の誤った所有者チェックが削除されました。  (Tom Lane) (13)(12)(11)(10)</li>
<p>
以前のマイナーリリースで、サーバでの SSL 秘密鍵のアクセス権チェック方式を libpq にも適用しましたが、所有者チェックまで同様に行うべきではありませんでした。鍵ファイルにアクセス可能であるけれども所有者と異なるユーザでクライアントを実行するときに、予期せぬエラーが生じることがありました。
</p>
<pre>
(エラー例: root で root 以外のユーザが所有者の鍵ファイルを指定して psql を実行）
$ su -
# PGSSLCERT=/ssl/cert.pem PGSSLKEY=/ssl/key.pem PGSSLROOTCERT=/ssl/rcert.pem \
  PGSSLMODE=verify-ca psql -h localhost -U postgres -d postgres
psql: error: private key file "key.pem" must be owned by the current user or root
</pre>
<li>ecpg でサーバ接続が失われた場合のエラーを適切に報告するようになりました。  (Tom Lane) (13)(12)(11)(10)</li>
<p>
接続が失われた場合などに、libpq で生成されたエラー結果を誤って処理していたため、有用なエラーメッセージではなく「(null)」と出力されていました。また、古いリリースではクラッシュする可能性がありました
</p>
<li>PL/Perl のテストケースが Perl 5.36 で動作するように調整されました。  (Dagfinn Ilmari Mannsaker) (13)(12)(11)(10)</li>
<li>PostgreSQL ビルド中に複数の OpenLDAP がインストールされている場合に、古い libldap_r ライブラリを誤って使用しないように configure が修正されました。  (Tom Lane) (13)(12)(11)(10)</li>
<li>論理レプリケーションでマテリアライズドビューのヒープ書き換え一時テーブルを無視するようになりました。  (Euler Taveira) (10)</li>
<p>
「FOR ALL TABLES」指定のパブリケーションは、個別にテーブルを指定せず、全テーブルが複製対象となり、一時テーブルを複製しようとします。DDL 中のヒープ書き換え一時テーブルは除外されますが、マテリアライズドビューの書き換え中に作成された内部一時テーブルをカバーできませんでした。これにより、REFRESH MATERIALIZED VIEW 中に「logical replication target relation ... does not exist」というエラーが発生するリスクがありました。
</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 10.21 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/10-21/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Fri, 03 Jun 2022 00:00:40 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 10]]></category>
		<category><![CDATA[PostgreSQL 10.20]]></category>
		<category><![CDATA[PostgreSQL 10.21]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=10131</guid>

					<description><![CDATA[このリリースは 10.20 からの修正リリース（2022年5月12日リリース）です。 10.X からのアップデートではダンプ、リストアは不要です。 また、10.19 よりも前のバージョンからアップデートする場合には、10 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 10.20 からの修正リリース（2022年5月12日リリース）です。<br />
10.X からのアップデートではダンプ、リストアは不要です。<br />
また、10.19 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/10-19/ ">10.19 のリリース情報</a>も参照してください。</p>
<p><span id="more-10131"></span></p>
<h3>PostgreSQL 10.20 から 10.21 への変更点</h3>
<p>14.3、13.7、12.11、11.16、10.21 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>「セキュリティ限定された操作」のサンドボックス内では追加操作を制限するようにしました。  (Sergey Shinderuk, Noah Misch) (14)(13)(12)(11)(10)</li>
<p>
自動VACUUM、CLUSTER、CREATE INDEX、REINDEX、REFRESH MATERIALIZED VIEW、pg_amcheck では「セキュリティ限定された操作」による保護が有効化されるのが遅すぎたり、全く働かなかったりしていました。
</p>
<p>
データベース内に永続オブジェクトを作成する権限を持ったユーザは、スーパーユーザ権限で任意の SQLコードを実行するオブジェクトを定義できました。仕込まれた SQLコードは、次に自動VACUUM が行われるときに、あるいは、スーパーユーザがそのオブジェクトに作用するいずれかのコマンドを実行したときに、実行されます。
</p>
<p>
本脆弱性は CVE-2022-1552 として登録されています。
</p>
<li>gist_ltree_ops のインデックスについて、デフォルトのシグネチャ長が修正されました。  (Tomas Vondra, Alexander Korotkov) (14)(13)</li>
<p>
ltree拡張を演算子クラスパラメータをサポートするようにアップグレードするときに、ltree列に対する GiSTインデックスのデフォルトのシグネチャ長（ハッシュサイズ）が、意図せず変更されてしまいました。最初から ltree をバージョン 1.2 にアップグレードしている場合を除き、このようなインデックスに何らか操作が行われた場合、シグネチャ長が 8バイトではなく 28バイトと見做されて動作します。したがって、おそらくそのインデックスは壊れています。安全のためバージョンアップ後に全ての ltree の列に対する GiSTインデックスを再作成（REINDEX）することを推奨します。なお、ltree[] 配列の列に対する GiSTインデックスには影響しません。
</p>
<li>素のテーブルを参照する行全体の値の列に対して、問い合わせで指定された列の別名を使わないようにしました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
選択リストの最上位以外での tbl.*などの行全体変数から作られたタプルの列名は、今後は、もしあるなら常に関連して名前付けされた複合型の要素名になります。これまでは FROM のエントリに適用された全ての列の別名を追跡させるように試みていました。しかし、これは意味がないと判断されました。
</p>
<p>
従来実装では、行全体をあらわす列を使用したテーブルを作った後、行全体の列の元となるテーブルの列名を付け直した場合に、そのようなテーブルのSELECT で予期せぬエラーが発生して、格納したデータが読めなくなってしまうことがありました。
</p>
<pre>
（報告された障害発生ケース）
db=# CREATE TABLE t3 (data int);
db=# CREATE VIEW v3 AS SELECT t3 FROM t3;
db=# CREATE TABLE t3_log (ts timestamp, what v3);

（列名を付け直す操作）
db=# ALTER TABLE t3 ADD big_data bigint;
db=# UPDATE t3 SET big_data = data;
db=# UPDATE t3_log SET what.t3.big_data = (what).t3.data;
db=# ALTER TABLE t3 DROP data;
db=# ALTER TABLE t3 RENAME big_data TO data;
db=# INSERT INTO t3 VALUES (123456);
db=# INSERT INTO t3_log SELECT now(), v3 FROM v3;

（この時は正しく出力）
db=# SELECT * FROM t3_log;
             ts             |     what
----------------------------+--------------
 2022-05-16 13:49:54.862458 | ("(123456)")
(1 row)
db=# \c

（接続し直した後にはエラーになる）
db=# SELECT * FROM t3_log;
ERROR:  record type has not been registered
</pre>
<p>
列名を付け直したい場合の本障害の回避策は、副問い合わせの階層を追加して、行全体の変数が副問い合わせの出力を参照して、素のテーブルを参照しないようにすることです。これは上記のエラー発生例で言えば「CREATE VIEW ...」を「CREATE VIEW v3 AS SELECT v::t3 AS t3 FROM (SELECT * FROM t3) v(d);」と記述することです。
</p>
<li>interval型からエポック値を抽出するときの誤った丸めが修正されました。  (Peter Eisentraut) (14)</li>
<p>
numeric型を返すようになった新しい EXTRACT の実装コードで、誤って DAYS_PER_YEAR 定数を整数型に変換して切り捨てていたため、13.x バージョン以前の float型を返すコードと戻り値が異なっていました。
</p>
<li>pg_stat_get_replication_slot(NULL) 実行時のクラッシュが防止されました。  (Andres Freund) (14)</li>
<p>
この関数はカタログデータで STRICT と定義されるべきでしたが、バージョン14 ではこれが指定されていなかったため、代替策として、関数実装に実行時のチェックが追加されました。
</p>
<li>table_to_xmlschema() などの XML関数における timestamptz型、timetz型の誤った出力が修正されました。  (Renan Soares Lopes) (14)(13)(12)(11)(10)</li>
<p>
これらのデータ型に対する XMLスキーマ出力では文字列パターンの正規表現が壊れていました。
</p>
<li>列数がゼロの「VALUES」句のパーサ処理のクラッシュが回避されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<pre>
（報告された障害発生ケース）
db=# CREATE TEMP TABLE nocols();
db=# INSERT INTO nocols DEFAULT VALUES;
db=# SELECT * FROM nocols n, LATERAL (VALUES(n.*)) v;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
</pre>
<li>プランノードの Result が Append ノードのすぐ下にあらわれる場合のプランナのエラーやクラッシュが修正されました。  (Etsuro Fujita) (14)</li>
<p>
非同期リモートクエリをサポートするために最近追加されたコードは、このケースを処理できず、クラッシュや「ERROR:  unrecognized node type ..」などの認識されないノードタイプに関するエラーが引き起こされました。
</p>
<li>「SEARCH」句または「CYCLE」句を使用するクエリに重複するテーブル式の名前が含まれている場合のプランナのエラーやクラッシュが修正されました。  (Tom Lane, Kyotaro Horiguchi) (14)</li>
<p>
再帰的な WITH クエリの名前が自身の中で再利用されると、プランナがクラッシュしたり、奇妙なエラーを報告したりする可能性がありました。
</p>
<pre>
（障害発生例）
db=# WITH RECURSIVE x(col) as (
       SELECT 1 UNION (
	     WITH x AS (SELECT * FROM x)
           SELECT * FROM x)
     ) SEARCH DEPTH FIRST BY col SET seq
     SELECT * FROM x;
ERROR:  could not find attribute 2 in subquery targetlist
</pre>
<li>外側のクエリ階層を参照する GROUPING() 構文のプランナエラーが修正されました。  (Richard Guo, Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
奇妙なエラーやアサート失敗が報告されました。
</p>
<pre>
（エラー発生例）
db=# SELECT (SELECT GROUPING(v1)) FROM (VALUES ((SELECT 1))) v(v1) GROUP BY v1;
ERROR:  plan should not reference subplan's variable
</pre>
<li>返却可能な列と返却不可能な列の両方を持つインデックスに対するインデックスオンリースキャンのプラン生成が修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
以前のコーディングでは、返却可能な列に加え、返却不可能な列も読み取ろうとする可能性がありました。 これは実際には無効な値に対して何も行わなかったためおよそ無害でしたが、最近追加されたエラーチェックでそのようなプランを拒否して、下記のエラーメッセージを出していました。
</p>
<pre>
ERROR:  XX000: variable not found in subplan target list
</pre>
<li>EvalPlanQual の実行中に古いタプルをロックしようとする際に、ピン(PIN)で固定されなくなった共有バッファにアクセスしないようになりました。  (Tom Lane) (14)(13)(12)</li>
<p>
EvalPlanQual は READ COMMITTED 隔離レベルの問い合わせにおける内部的な処理です。
</p>
<p>
従来コードはピンを解放した後、さらに数回バッファにアクセスしていました。理論的には別プロセスがピンがなくなった時点ですぐにバッファを再利用し（あるいは、より可能性が高いのは、その空き領域をデフラグしようとし）、タプルの新しいバージョンを見つけるのに失敗する可能性があります。
</p>
<li>再並べ替えを実行している IndexScanノードでの、クエリ存続期間におけるメモリリークが修正されました。  (Aliaksandr Kalenik) (14)(13)(12)(11)(10)</li>
<li>関数の並列性属性と「SET」変数リストを同じコマンドで変更できるように ALTER FUNCTION が修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
一つの ALTER FUNCTION コマンドで関数の「SET」句も更新した場合、並列性属性の変更が失われていました。
</p>
<pre>
（誤動作例／「PARALLEL safe」を指定したので proparallel は 「s」が正しい）
db=# CREATE FUNCTION public.f14() RETURNS int LANGUAGE sql AS 'SELECT 1';
db=# ALTER FUNCTION public.f14() SET timezone TO 'UTC' PARALLEL safe;
db=# SELECT proname, proparallel, proconfig FROM pg_proc WHERE proname = 'f14';
 proname | proparallel |   proconfig
---------+-------------+----------------
 f14     | u           | {TimeZone=UTC}
(1 row)
</pre>
</p>
<li>制約に「所有されている」インデックスの検出が厳格化されました。  (Tom Lane, Japin Li) (14)</li>
<p>
一部のコードパスで、外部キー制約が依存しているインデックスを、ユニーク制約または主キー制約によって所有されているインデックスと取り違えていました。その結果、外部キー制約を持つテーブルに対する特定の ALTER TABLE 操作に際して、下記のような奇妙なエラーが発生していました。
</p>
<pre>
 ERROR:  relation 145678 has multiple clustered indexes 
または
 ERROR:  "t15_pkey" is not an index for table "t15" 
</pre>
<li>ALTER TABLE でテーブルのシステム列を変更しようとすると、間違ったエラーが発生する問題が修正されました。  (Tom Lane) (14)(13)(12)</li>
<p>
システムは「ERROR:  cannot alter system column "cmax"」などと、それができないことを通知するべきですが、代わりに「ERROR:  no owned sequence found」を報告する場合がありました。
</p>
<li>先頭キーが式であるインデックスを使用して CLUSTER 処理を行った場合に、テーブルの行が誤った並べ替えになる問題が修正されました。  (Peter Geoghegan, Thomas Munro) (14)(13)(12)(11)(10)</li>
<p>
テーブルは正しいデータで再構築されますが、インデックスの順序とはほとんど関係のない順序になりました。
</p>
<li>ソートされた GiSTインデックスのビルド直後にシステムクラッシュが発生した場合のデータ損失が防止されました。  (Heikki Linnakangas) (14)</li>
<p>
ソートを使用して GiSTインデックスを構築するコードパスは、完了時にファイルの fsync を怠っていました。このため、その後すぐにオペレーティングシステムがクラッシュした場合、インデックスが破損する可能性がありました。
</p>
<li>パーティション化されたインデックスを削除する際にデッドロックエラーのリスクがあり、修正されました。  (Jimmy Yih, Gaurab Dey, Tom Lane) (14)(13)(12)(11)</li>
<p>
必要なテーブルとインデックスのロックが確実に標準的な順序（子の前に親、インデックスの前にテーブル）で取られるようになりました。DROP INDEX の以前のコーディングでは、これとは異なる方法でロックを取っていたため、標準的な順序でこれらのロックを取る同時実行の問い合わせに対してデッドロックが発生する可能性がありました。
</p>
<li>DROP TABLESPACE とチェックポイントの間の競合状態が修正されました。  (Nathan Bossart) (14)(13)(12)(11)(10)</li>
<p>
DROP TABLESPACE によって強制されるチェックポイントが、テーブルスペースのディレクトリからすべてのデッドファイルを削除することに失敗して、以下のような偽のエラーが発生する場合がありました。
</p>
<pre>
ERROR:  tablespace "tblspc20" is not empty
</pre>
<li>チェックポイント実行と並行して TRUNCATEコマンドを実行した後に、クラッシュリカバリが失敗する可能性があり、修正されました。  (Kyotaro Horiguchi, Heikki Linnakangas, Robert Haas) (14)(13)(12)(11)(10)</li>
<p>
チェックポイントが完了できるようになる前に、テーブルのディスクファイルが全削除されることをTRUNCATE は保証しなければなりません。そうでないと、そのチェックポイントから開始したリプレイが、削除されているはずのページの予期せぬデータを見つけて、リプレイ失敗を引き起こすおそれがありました。
</p>
<li>一時オブジェクト削除中における安全でないTOASTデータアクセスが修正されました。  (Andres Freund) (14)(13)(12)(11)(10)</li>
<p>
サーバプロセス終了時に「FATAL: cannot fetch toast data without an active snapshot」のエラーを出して、一時オブジェクトの削除に失敗することがありました。次に一時スキーマを使う際に正常にクリーンアップされるため、通常は無害です。
</p>
<li>カスタム設定名の最初の文字に「_」が再度使えるようになりました。  (Japin Li) (14)</li>
<p>
バージョン14 ではそのような名前が意図せず使えなくなってしまっていました。
</p>
<li>compute_query_id 設定に指定可能な値として「regress」が追加されました。  (Michael Paquier) (14)</li>
<p>
これはリグレッションテストを容易にすることを目的としており、クエリID が計算されるけれども EXPLAIN の出力には表示されません。
</p>
<li>RegisterSyncRequest の待機ロジックが改善されました。  (Thomas Munro) (14)(13)(12)</li>
<p>
RegisterSyncRequest は局所的にストレージ同期の要求を受け付けたり、要求を checkpointerプロセスに転送したりする、内部実装関数です。
</p>
<p>
その中で checkpointer への同期要求キューが溢れた場合（shared_buffers が小さい場合に起こりえます）、その待ち行列が減るのを待つ動作をします。このときの待機を示す待機イベント「RegisterSyncRequest」が追加されました。
</p>
<li>書き込みと書き込みの間で checkpointerプロセスが待機しているときにはラッチイベントを起こすようになりました。  (Thomas Munro) (14)</li>
<p>
これは同期リクエストを送信するバックエンドの反応性を改善します。更にこの待機に対応した待機イベント「CheckpointerWriteDelay」も追加されました。
</p>
<li>WAL の後続レコードが欠けている時にスタンバイを昇格すると「PANIC: xlog flush request is not satisfied」が発生する問題が修正されました。  (Sami Imseih) (14)(13)(12)(11)(10)</li>
<li>ホットスタンバイのコンフリクトを処理する際に自己デッドロックが起きる可能性があり、修正されました。  (Andres Freund) (14)(13)(12)(11)(10)</li>
<p>
不運なタイミングのとき、WAL を適用するプロセスが他プロセスのバッファロックの解放を待って、動作が止まってしまう可能性がありました。
</p>
<li>ロジカルレプリケーションの変更を送信する際、パーティションの先祖関係を間違ってしまう可能性があり、修正されました。  (Tomas Vondra, Hou zj, Amit Kapila) (14)(13)</li>
<p>
publish_via_partition_root オプションが true に指定されていて、更新するリレーションに対する異なる先祖で指定された複数のパブリケーションがある場合（即ち親子関係にあるリレーション各々にパブリケーションを作っている場合）、サブスクリプションへの変更の報告に際して間違った先祖リレーションを選択することがありました。
</p>
<li>max_sync_workers_per_subscription 設定の制限に抵触する場合でもロジカルレプリケーションの apply workerプロセスが再起動されるようになりました。  (Amit Kapila) (14)(13)(12)(11)(10)</li>
<p>
本設定に対する上限検査コードの欠陥により、これまでは再起動されたワーカを直ぐに終了してしまっていて、ほとんどのワーカが存続できませんでした。
</p>
<li>UPDATE に対して、変更されていないレプリカアイデンティティ（REPLICA IDENTITY）のキー列を、それが外部TOAST格納されている場合には WALログに含めるようになりました。  (Dilip Kumar, Amit Kapila) (14)(13)(12)(11)(10)</li>
<p>
この対処をしないと、サブスクライバはその値を見ることができないので、更新を正しく複製できないことになります。
</p>
<li>psコマンドにおけるサーバプロセス表示の置き換えに対応していないプラットフォームを適切に処理できるようになりました。  (Andrew Dunstan) (14)(13)</li>
<p>
このようなプラットフォームはほとんどありません。そのため、これまでリファクタリングが潜在的なメモリ破壊をもたらすことに気づかれませんでした。サポートされているプラットフォームで該当する唯一のものは Cygwin で、バックエンドプロセスのクラッシュが報告されました。
</p>
<li>タイマ割り込みの見逃しに対して、より頑健になりました。  (Michael Harris, Tom Lane) (14)</li>
<p>
バージョン14 で追加された最適化は、なんらかの理由でサーバプロセスがタイマ割り込みを逃してしまった場合は他についてもカーネルに要求を繰り返さないというもので、セッションの以降においてタイムアウト検出に失敗することになりました。
</p>
<p>
これでは脆弱すぎると判断され、リカバリパスが追加されました。
</p>
<li>PL/Perl関数のコンパイル時には SPI関数は実行できないようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
PL/Perl関数のコンパイル時には Perl はユーザ定義コードを実行すると考えられます。しかしながら、SPI 経由の SQL操作を行うコードは望ましくなく、クラッシュかセキュリティ障害を起こす可能性がありました。関数の検証に際して本当にコード実行をしたいわけではありません。そこで、代わりに親切なエラーメッセージを出す検査が加えられました。
</p>
<li>libpq が root所有の SSL秘密鍵ファイルを受け入れるようになりました。  (David Steele) (14)(13)(12)(11)(10)</li>
<p>
この変更により、libpq の SSL鍵ファイルの所有者とアクセス許可の安全チェックが、バージョン9.6 以降のサーバと統一されます。すなわち、現在のルールに加え、鍵ファイルの所有者が root であって、パーミッションが 0640 以下の場合を許容するようになりました。これは、鍵ファイルのシステム全体での管理に役立ちます。
</p>
<li>libpq の PQisBusy()関数の接続エラー後の動作が修正されました。  (Tom Lane) (14)(13)(12)</li>
<p>
書き込みエラーを検出した場合、PQisBusy() は常に真を返しましたが、これは誤りでした。サーバから何か読み取れるまで、通常は入力処理を継続したいところでした。
</p>
<p>
この障害の実際の影響は、libpq の非同期クエリAPI を使用するアプリケーションが、PQconsumeInput() が致命的なエラーを返した場合にしか接続断を検出しないことです。この修正により、接続断が順当にエラーの PGresult オブジェクトを介して報告されるようになりました。これはほとんどのアプリケーションにとって相応しい動作です。
</p>
<li>psql、pg_dump、および pg_amcheck で「データベース.スキーマ.テーブル」という構文を再度許容するようになりました  (Mark Dilger) (14)</li>
<p>
14 より前のバージョンは、2つ以上の「.」を含むパターンにおけるスキーマとテーブル以外の全ての修飾名を黙って無視していました。バージョン14 でのリファクタリングの誤りで、そのユースケースがエラーになるようになってしまいました。本バージョンで復活しましたが、先頭の修飾名がカレントデータベースの名前と一致しない場合にはエラーが発生します。
</p>
<pre>
（バージョン 14.2 で以下エラー／13.x 以前と 14.3 以降では実行可能）
db1=# \d db1.public.t1
Did not find any relation named "db1.public.t1".

（バージョン14.3 で以下エラー／13.x 以前では実行可能）
db1=# \d foo.bar.public.t1
improper qualified name (too many dotted names): foo.bar.public.t1
</pre>
<li>pg_ctl は、stop/restart/promote の動作を待機している間、postmasterプロセスが動作していることを再チェックするようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
pg_ctl は、stop または promote シグナルを送信する一方で postmasterプロセスが動作していること（PID が有効であるか）を 1回確認しますが、その後は単純に PIDファイルが削除されるまで待機していました。postmaster が PIDファイルを削除したり、制御ファイルを更新したりせず、非正常に終了した場合、pg_ctl はタイムアウトになるまで待機していました。
</p>
<p>
これに替えて postmasterプロセスがまだ存在しているかをときどき再チェックするようになりました。
</p>
<li>pg_waldump のエラー処理が修正されました。  (Kyotaro Horiguchi, Andres Freund) (14)(13)(12)(11)</li>
<p>
WALセグメントサイズを知るために WALファイルを読み取ったとき、ファイルサイズが XLOG_BLCKSZ よりも小さい場合（例えば 0バイト）、pg_waldump は誤ったエラー報告をしていました。また、このエラーメッセージおよび関連するエラーメッセージで報告されるファイル名は無効である可能性がありました。
</p>
<pre>
（報告された誤ったメッセージ／正しくないファイル名や要因が示される）
pg_waldump: fatal: could not read file ".....": .....
</pre>
<li>contrib/pageinspect の関数が全てゼロのページに対応するようになりました。  (Michael Paquier) (14)(13)(12)(11)(10)</li>
<p>
これは正当な境界条件的ケースでしたが、このモジュールではほぼ想定されていませんでした。必要に応じて、NULL を返すか、行を返さないように変更されました。これは、エラーを発生させるよりも有効です。
</p>
<li>contrib/pageinspect で、破損したページの「特別な領域」に対する保護を追加し、正しいページサイズのチェックを強化し、不足していたインデックスの型チェックが追加されました。  (Michael Paquier, Justin Pryzby, Julien Rouhaud) (14)(13)(12)(11)(10)</li>
<p>
これらの変更により、モジュールが不良データでクラッシュする可能性が低くなりました。
</p>
<li>contrib/postgres_fdw で BEFORE INSERT ... FOR EACH ROW トリガが外部テーブルに存在する場合、バッチ挿入が無効にされました。  (Etsuro Fujita) (14)</li>
<p>
このようなトリガはテーブルを照会する際、手前で挿入した行を参照するかもしれません。バッチ挿入では、これらの行がまだ可視となってない可能性があるため、予期せぬ動作を回避するため、無効にされました。
</p>
<li>contrib/postgres_fdw で、リモートで順序付けされたクエリを要求する前にORDER BY句が安全に渡せることを検証し、必要に応じて USING句を含めるようになりました。  (Ronan Dunklau) (14)(13)(12)(11)(10)</li>
<p>
この修正はリモートサーバが意図と異なる順序で並べ替えるケースを防止します。これは見た目だけの場合もありますが、リモートデータがローカルで実行されるマージ結合の入力として使用されると、完全に間違った結果が生じる可能性がありました。
</p>
<li>sys/epoll.h があり、sys/signalfd.h はないプラットフォームを扱えるようにconfigure が修正されました。  (Tom Lane) (14)</li>
<li>LLVM 14 で動作するように JITコードが更新されました。  (Thomas Munro) (14)(13)(12)(11)</li>
<li>clang の -fsanitize=undefined オプションで様々な障害をクリーンアップするようになりました。  (Tom Lane, Andres Freund, Zhihong Yu) (14)(13)(12)(11)(10)</li>
<p>
これらの変更のほとんどは、C および POSIX 標準の文書に型通りに準拠するためのものであり、本番ビルドに影響を与える可能性はほとんどありません。
</p>
<li>OpenSSL なしでビルドする場合は、libpq の pkg-config ファイルに OpenSSL の依存関係を追加しないように修正されました。  (Fabrice Fontaine) (14)</li>
<li>式の中にネストされたステートメントをサポートしない CコンパイラでビルドできるようにPL/Perl が修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<li>Windows でビルドに MSVC を使用していない場合に、pg_dumpall のビルドエラーが発生する可能性があり、修正されました。  (Andres Freund) (14)(13)(12)(11)(10)</li>
<p>
mingw の gcc によるビルドで問題が報告されました。
</p>
<li>Windowsビルドでは、pexports の代わりに gendef を使用してDEFファイルを作るようになりました。  (Andrew Dunstan) (14)(13)(12)(11)(10)</li>
<p>
これにより、ビルドプロセスが最新の MSys ツールチェーンで機能するように調整されました。
</p>
<li>MinGW でビルドされたプログラムでの余分なワイルドカードパターンの展開が防止されました。  (Andrew Dunstan) (14)(13)(12)(11)(10)</li>
<p>
何らかの理由で、MinGW によって提供される Cライブラリは、デフォルトでプログラムのコマンドライン引数のシェルワイルドカード文字を展開してしまいます。MSVC では特に発生しないため、これは混乱を招くのでパターン展開が無効化されました。
</p>
<li>タイムゾーンデータファイルが tzdata release 2022a に更新されました。パレスチナでの夏時間法の変更に加えて、チリ、ウクライナの歴史的修正が含まれます。   (14)(13)(12)(11)(10)</li>
<li>論理レプリケーションのサブスクライバにおける、サポートされていないテーブル種別に対するエラーメッセージが改善されました。  (Tom Lane) (12)(11)(10)</li>
<p>
バージョン13 以降のサーバは、パーティションテーブルのパブリッシュがサポートされるようになりました。バージョン13 より古いバージョンのサーバは、パーティションテーブルのサブスクライブを処理できず、「table ... not found on publisher」のような誤解を招くエラーメッセージを表示していましたが、より的確なメッセージを表示するように修正されました。
</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 10.20 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/10-20/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Thu, 17 Mar 2022 05:50:08 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 10]]></category>
		<category><![CDATA[PostgreSQL 10.19]]></category>
		<category><![CDATA[PostgreSQL 10.20]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=9406</guid>

					<description><![CDATA[このリリースは 10.19 からの修正リリース（2022年2月10日リリース）です。 11.X からのアップデートではダンプ、リストアは不要です。 しかしながら、本リリースで修正されたいくつかの障害により既にインデックス ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 10.19 からの修正リリース（2022年2月10日リリース）です。<br />
11.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、本リリースで修正されたいくつかの障害により既にインデックスに破損が生じている可能性があるため、該当するインデックスを再構築することが推奨されます。<br />
また、10.19 よりも前のバージョンから移行する場合には <a href="/tech-blog/pgsql/10-19">10.19 のリリース情報</a>も確認してください。</p>
<p><span id="more-9406"></span></p>
<h3>PostgreSQL 10.19 から 10.20 への変更点</h3>
<p>14.2、13.6、12.10、11.15、10.20 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>REINDEX CONCURRENTLY の問題を防止するため、TOAST テーブルの更新に標準のロックプロトコルが適用されました。  (Michael Paquier) (14)(13)(12)</li>
<p>
REINDEX CONCURRENTLY を TOASTテーブルまたは TOASTテーブルのインデックスに 適用した場合、破損したインデックスを生成することがよくありました。これは TOASTエントリを更新するセッションが、他の更新の動作と同様にトランザクションがコミットされるまで ROW EXCLUSIVE ロックを保持するのではなく、ROW EXCLUSIVE ロックをすぐに解放したために発生しました。今回 TOAST 更新が通常のルールに従ってテーブルロックを保持するよう修正されました。既存の破損したインデックスは、再度 REINDEX を実行することで修復できます。
</p>
<li>ページプルーニング中に RECENTLY_DEAD タプルが状態を完全に DEAD に変更した時の HOTチェーンの破損が修正されました。  (Andres Freund) (14)</li>
<p>
VACUUM では、それを指すリダイレクトアイテムが残っている状態で RECENTLY_DEAD のタプルを削除することがありえました。そのようなタプルのアイテムスロットが後に新しいタプルで再利用されると、既存の HOTチェーンの一部とみなされ、インデックス破損が形成されます。
</p>
<p>
発生した場合はテーブルのインデックス再作成で修復できます。しかし、これは非常に確率の低いシナリオであるため、発生したかもしれないという可能性だけでインデックスを再作成することは推奨されません。
</p>
<li>ローカルパーミッションと外部パーティションが混在するテーブルのEvalPlanQual再チェックでのクラッシュが修正されました。  (Etsuro Fujita) (14)</li>
<p>
EvalPlanQual再チェックは READ COMMITTED 隔離レベルの問い合わせで使われる処理です。
</p>
<li>COPY TO でのメモリ処理の誤りが修正されました。  (Bharath Rupireddy) (14)</li>
<p>
この見落としにより、COPY でエラーが発生した後、誤ったエラーメッセージやクラッシュが発生することがありました。
</p>
<li>同時に DROP STATISTICS で統計オブジェクトが削除された時に発生する ALTER STATISTICS での NULLポインタ参照によるクラッシュが回避されました。  (Tomas Vondra) (14)(13)</li>
<li>マルチ範囲型データから範囲を抽出する際に、アライメントのパディングが正しく処理されるようになりました。  (Alexander Korotkov) (14)</li>
<p>
この誤りは可変長データ型のマルチ範囲を処理する際にクラッシュを引き起こす可能性がありました。
</p>
<li>無名 RECORD データ型に対するハッシュの過度な楽観的使用が修正されました。  (Tom Lane) (14)</li>
<p>
これにより、「ERROR:  could not identify a hash function for type record」（型レコードのハッシュ関数を識別できない）のエラーが防止されます。
</p>
<li>パラレルで単一の子ノードを持つ Appendノードに対する誤ったプラン作成が修正されました。  (David Rowley) (14)(13)(12)</li>
<p>
場合によっては、Append が単純化されるべきではない時に単純化され、誤った問い合わせ結果（重複した行）が発生することがありました。
</p>
<p>
単一の子ノードを持つ Appendノードは、例えば「SELECT id, c FROM t1 UNION ALL SELECT id, c FROM t2 WHERE false」といった形を持つ問い合わせのプランで出現する可能性がありました。
</p>
<li>インデックスに返却不能の列が含まれる場合について、インデックスオンリースキャンプランが修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
インデックスの列にはインデックスオンリースキャンで返すことができるか（返却可能列か返却不能列か）を示す、returnable属性があります。
</p>
<p>
インデックスが返却可能列と返却不能列の両方を持ち、返却不能列の 1つが返却可能列にあらわれるテーブル列を使用した式である場合、その式を使用した問い合わせは、返却可能列から式を再計算するのではなく、返却不能列を読もうとするインデックスオンリースキャンプランとなる可能性がありました。返却不能列は NULL として読み込まれるため、誤った問い合わせ結果が発生しました。
</p>
<pre>
（障害動作例／ここでの lower(c) は返却不能列）
db=# CREATE TABLE t9 (c text);
db=# INSERT INTO t9 VALUES (md5('A')), (md5('B'));
db=# CREATE INDEX ON t9 USING gist(lower(c) gist_trgm_ops) INCLUDE (c);
db=# SET enable_seqscan TO off;
db=# \pset null *NULL*
db=# SELECT lower(c), c FROM t9;
 lower  |                c
--------+----------------------------------
 *NULL* | 7fc56270e7a70fa81a5935b72eacbe29
 *NULL* | 9d5ed678fe57bcca610140957afab571
(2 rows)
</pre>
<li>Memoize の上位からきたパラメータを使用するサブプランを処理できるように、Memoizeプランノードが修正されました。  (David Rowley) (14)</li>
<p>
この障害により誤った問い合わせ結果が生じるケースが報告されました。
</p>
<li>Memoizeプランノードがハッシュ不可能な結合の演算子で正しく動作するように修正されました。  (David Rowley) (14)</li>
<p>
結合条件に不等号を使っている場合や浮動小数点データ型で 0.0 と -0.0 がある場合などで問題が生じました。この障害により、クラッシュや誤った問い合わせ結果が生じる可能性があります。
</p>
<li>指定されていない型修飾へのキャストにより、長さの強制関数の呼び出しではなく、RelabelTypeノードが生成されるようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
強制関数は正しい動作（何もしないこと）を実行しますが、この変換は非効率で望ましくありません。
</p>
<p>
character(N) 型を bpchar 型にキャストする場合が該当します。
</p>
<li>anycompatible で始まる名前の疑似データ型（以下「anicompatible*」と記載）について一致判定が修正されました。  (Tom Lane) (14)(13)</li>
<p>
anicompatible* 型の多相パラメータを持つ関数や演算子が、実際には本当は一致しないはずの引数の集合に一致したと、パーサが誤判断することがありました。
</p>
<p>
報告されたケースでは、一つの呼び出しに複数の演算子を一致させることになり、「ERROR:  operator is not unique: ...」「HINT:  Could not choose a best candidate operator. You might need to add explicit type casts.」などのあいまいな演算子だというエラーを引き起こしました。一方、より後の処理段階でエラーを起こすこともあり得ました。
</p>
<li>ちょうど WALページの境界でデータベースが整合性を持つ状態に到達した場合の、WALリプレイ失敗が修正されました。  (&Aacute;lvaro Herrera) (14)(13)(12)(11)(10)</li>
<p>
修正されませんが、これは 9.6.x でも該当します。
</p>
<li>物理ストリーミングレプリケーションのスタンバイサーバの startup処理がトランザクションID 周回を許容するように修正されました。  (Abhijit Menon-Sen, Tomas Vondra) (14)(13)(12)(11)(10)</li>
<p>
プライマリ上のアクティブなトランザクションのセットが周回境界を越えている間にスタンバイサーバが起動すると（古いトランザクションよりも小さい XID を持つ新しいトランザクションがいくつか存在するため）、「ERROR: out-of-order XID insertion in KnownAssignedXids」エラーが生じました。再試行されますがこのエラーを乗り越えることはできません。
</p>
<li>ロジカルレプリケーションで子テーブルのデータの二重送信が回避されるようになりました。  (Hou Zhijie) (14)(13)</li>
<p>
パブリケーションに子テーブルと親テーブルの両方が含まれ、publish_via_partition_root オプションが設定されている場合、サブスクライバは子テーブルと親テーブルの両方で無駄な同期を開始していました。このような場合は親テーブルのみが同期されるようになりました。
</p>
<li>ロジカルレプリケーション接続で発行される SQLコマンドの字句制限が撤廃されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
これまでは、引用符で囲まれていないセミコロンを含む SQLコマンド、奇数の一重引用符または二重引用符を含むドル引用符で囲まれたリテラル、または SQLコマンドがコメントで始まる場合、walsenderプロセスがエラーを起こしました。
</p>
<p>
さらに、不完全なエラーからの回復処理により以降のコマンドでも予期せぬエラーが発生する可能性がありました。
</p>
<li>ROLLBACK PREPARED 操作のレプリケーションに際して、レプリケーション元のタイムスタンプが確実に設定されるようになりました。  (Masahiko Sawada) (14)</li>
<li>トランザクションの最後のサブトランザクションのコミットタイムスタンプが記録されない可能性があり、修正されました。  (Alex Kingsborough, Kyotaro Horiguchi) (14)(13)(12)(11)(10)</li>
<li>チェックポイントに際して、pg_logical/mappingsサブディレクトリを必ず fsync するようになりました。  (Nathan Bossart) (14)(13)(12)(11)(10)</li>
<p>
一部のファイルシステムでは、この見落としによりシステムクラッシュ後に論理書き換えの状態ファイルが失われる可能性がありました。
</p>
<li>パーティションテーブルの拡張統計情報が作成されるようになりました。  (Justin Pryzby) (14)(13)(12)(11)(10)</li>
<p>
以前のバグ修正により、古い形式の継承ツリーに対する拡張統計の構築が無効になりましたが、パーティションテーブルに対する構築も無効になっており、不要な制限となっていました。今回の変更により、ANALYZE はパーティションテーブルの統計オブジェクトの値を計算できるようになりました。（しかし、autovacuum はパーティションテーブルを自動処理しないので、パーティションテーブルの統計情報を維持したい場合は、パーティションテーブルに対して定期的に手動 ANALYZE を実行する必要があることに注意してください。）
</p>
<li>継承ツリーの拡張統計情報を無視するようになりました。  (Justin Pryzby) (14)(13)(12)(11)(10)</li>
<p>
現在、拡張統計情報の値は継承ツリー全体ではなく各テーブルに対してローカルでのみ計算されます。しかし、この値が継承ツリーをまたがる問い合わせを計画する際に誤って参照されたため、デフォルトよりも悪い推定値になる可能性がありました。
</p>
<li>パーティションテーブルの行型が他の場所で複合型として使用されている場合、パーティションテーブルの列のデータ型を変更することが禁止されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
この制限は通常のテーブルでは長い間存在していましたが、見落としによりパーティションテーブルではチェックされていませんでした。
</p>
<li>レプリカアイデンティティ(REPLICA IDENTITY) のインデックスの一部である列に対する ALTER TABLE ... DROP NOT NULL が禁止されました。  (Haiying Tang, Hou Zhijie) (14)(13)(12)(11)(10)</li>
<p>
同じ禁止事項はすでに主キーインデックスに存在していました。
</p>
<li>ALTER TABLE .. ADD PRIMARY KEY USING INDEX の実行に際して、キャッシュされたテーブルの状態が正しく更新されるようになりました。  (Hou Zhijie) (14)(13)(12)(11)</li>
<p>
同時実行中のセッションが、テーブルに主キーがあるかどうかに関する判定を更新できなかったため、不正なロジカルレプリケーションの動作が発生する可能性がありました。
</p>
<p>
パブリケーションしているテーブルの UPDATE で、テーブルに ALTER TABLE で主キーを設定した後であっても、以下エラーが発生する動作が報告されました。
</p>
<pre>
ERROR:  cannot update table ... because it does not have a replica identity and publishes updates
</pre>
<li>REPLICA IDENTITY インデックスから切り替えを行う際、キャッシュされたテーブルの状態が正しく更新されるようになりました。  (Tang Haiying, Hou Zhijie) (14)(13)(12)(11)(10)</li>
<p>
同時実行中のセッションが、どのインデックスが REPLICA IDENTITY であるかの判定を更新できなかったため、不正なロジカルレプリケーションの動作が発生する可能性がありました。
</p>
<li>SP-GiSTインデックス作成で、インデックス対象列のデータ型が演算子クラスの宣言された入力型とバイナリ互換性がある場合でもエラーとなっていたのが修正されました。  (Tom Lane) (14)</li>
<p>
このような場合は動作すべきでしたが以下のエラーが発生していました。
</p>
<pre>
ERROR:  compress method must be defined when leaf type is different from input type
</pre>
<li>最も古い xmin値を計算する際、並列のバキュームとインデックス同時構築を無視できるようにようになりました。  (Masahiko Sawada) (14)(13)</li>
<p>
並列化されていない処理では既に無視されていましたが、並列化されたロジックでは機能していませんでした。その結果、xmin の限界値の前進が抑えられることで、バキュームのクリーンアップが遅れるなどの望ましくない影響がありました。
</p>
<li>式インデックスを更新するときのメモリリークが修正されました。  (Peter Geoghegan) (14)</li>
<p>
式インデックスを持つテーブルの多くの行を更新する UPDATE 文は、大量のメモリを消費する可能性がありました。
</p>
<li>多数のオブジェクトの所有権を変更する REASSIGN OWNED BY コマンド実行中にメモリリークが発生しないように修正されました。  (Justin Pryzby) (14)(13)(12)(11)(10)</li>
<li>不要なキャッシュアクセスを回避することにより、ロジカル変更を送信する walsender のパフォーマンスが向上しました。  (Hou Zhijie) (14)(13)</li>
<li>pg_hba_file_rules ビューでの cert認証方式のオプションの表示が修正されました。  (Magnus Hagander) (14)(13)(12)</li>
<p>
認証方式が cert の場合、clientcert=verify-full が暗黙的に指定されますが、pg_hba_file_rules ビューは誤って clientcert=verify-ca と報告していました。
</p>
<li>pg_log_backend_memory_contexts() で対象とされるセッションが、結果をサーバのログのみに送信するよう修正されました。  (Fujii Masao) (14)</li>
<p>
以前は、client_min_messages のレベルを高く設定すると、接続しているクライアントにもログメッセージが送信される可能性がありました。これはクライアントが要求していない動作です（そしておそらくワイヤープロトコル違反でした）。
</p>
<li>INSERT .. VALUES のルールにおける行全体の変数の表示方法が修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
行全体の変数は、var.* として出力されますが、ルールが再ロードされたときに個々の列に展開されるため、異なるセマンティクスとなっていました。これを防ぐために他の場所と同様に明示的なキャストが行われるようになりました。
</p>
<li>SQL標準の関数本体を逆コンパイルによって再構築したときに、INSERT ... SELECT 内の関数パラメータが適切に表示されるようになりました。  (Tom Lane) (14)</li>
<p>
これまでは、パラメータに名前が付いていても $n と出力されていました。
</p>
<li>空文字列に対して Unicode 文字列正規化を適用する場合の 1バイトのバッファオーバーランが修正されました。  (Michael Paquier) (14)(13)</li>
<p>
これによる実際の影響は、アライメントを考慮すれば限定的なものですが、デバッグビルドでは警告が発生していました。
</p>
<li>いくつかの誤ったアサートが修正または削除されました。  (Simon Riggs, Michael Paquier, Alexander Lakhin) (14)(13)(12)(11)(10)</li>
<p>
これらの誤りは、製品ビルドではなく、デバッグビルドのみ影響を受けました。
</p>
<li>libpq と ecpglib でマルチスレッド使用時における gettext() 初期化の競合状態が修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
エラーメッセージのローカライズに失敗する可能性がありました。
</p>
<li>libpq の PQcancel関数から strerror を呼び出さないようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
PQcancel はシグナルハンドラから安全に呼び出すことができるはずですが、strerror は安全ではありません。誤った使用法は、サーバへのキャンセルメッセージ送信に失敗した場合にのみ発生しますので、そのためおそらくこれまで報告がありませんでした。
</p>
<li>psql の \password コマンドで設定するパスワードは、接続元のユーザのものではなく、CURRENT_USER のものがデフォルトとなりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
これはドキュメントの動作と一致し、セッション開始後の SET ROLE または SET SESSION AUTHORIZATION を実行した場合に発生し得るパーミッションエラーを避けます。また、混乱を防ぐために操作対象のロール名がパスワードプロンプトに含まれるようになりました。
</p>
<li>親テーブルのトリガを識別するように psql の \d コマンドのクエリが修正されました。  (Justin Pryzby) (14)(13)</li>
<p>
パーティションにトリガがあり、親テーブルにも同じ名前の無関係な文レベルトリガが存在した場合、以前のコードでは「ERROR: more than one row returned by a subquery used as an expression」というエラーが発生していました。
</p>
<li>psql の \d コマンドで、テーブルの拡張統計オブジェクトが OID でなく名前でソートされるようになりました。  (Justin Pryzby) (14)</li>
<li>psql の列挙型のラベルをタブを使って補完する機能が修正されました。  (Tom Lane) (14)(13)</li>
<li>Windows の標準入力からの読み込みをデータソースまたは宛先に使用したときの障害が修正されました。  (Dmitry Koval, Juan Jose Santamaria Flecha, Michael Paquier) (14)</li>
<p>
これは、psql の \copy コマンド、または pg_recvlogical で「-f -」を付けた場合に影響がありました。「could not stat file」エラーが発生しました。
</p>
<li>psql や 他のクライアントプログラムでは、Ctrl+C シグナルハンドラからのgettext() 呼び出しを避けるようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
この誤りに起因する障害報告は確認されていませんが、gettext() は非同期シグナル安全な関数ではなく、安全とは言えません。
</p>
<li>pg_receivewal と pg_recvlogical の初期パスワード入力がキャンセルできるようになりました。  (Tom Lane, Nathan Bossart) (14)(13)(12)(11)(10)</li>
<p>
以前は、パスワード入力を求められている間、Ctrl+C でこれらのプログラムを終了することができませんでした。
</p>
<li>pg_dump がユーザ定義キャストをダンプするときの順序が、TYPE の直後、FUNCTION の手前に修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
まれに、出力スクリプトがユーザ定義キャストを作成する前に参照してしまう場合がありました。
</p>
<li>pg_dump の --inserts と --column-inserts モードが修正され、以前削除された列と生成列の両方を含むテーブルを扱えるようになりました。  (Tom Lane) (14)(13)(12)</li>
<li>pg_dump と pg_basebackup での誤ったエラー報告の可能性が修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
以前のコードでは、一部のカーネル呼び出しからのエラーをチェックできず、他のケースでは誤った errno 値を報告する可能性がありました。
</p>
<li>char(N) 列に対する contrib/btree_gist のインデックスによるインデックスオンリースキャン結果が修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
インデックスオンリースキャンでは末尾の空白が削除された列値が返されましたが、これはインデックス格納方法に起因したもので、想定の動作ではありませんでした。末尾空白の違いだけですが誤った問い合わせ結果です。
</p>
<p>
空白埋めをした char(N) 値を格納するようにコードが修正されました。インデックスの動作は REINDEX をしない限りすぐには反映されません。 REINDEX（インデックス再作成）をしない場合、空白が削除された値は、更新を行っていくなかで徐々に置き換えられていきます。インデックスオンリースキャン実行計画を使用しない問い合わせは、どの場合でも影響を受けません。
</p>
<li>postgres_fdw の非同期クエリの処理における稀なケースが修正されました。  (Etsuro Fujita) (14)</li>
<p>
これらのエラーは、外部テーブルのスキャンを並列化しようとすると、クラッシュまたは誤った問い合わせ結果を引き起こす可能性がありました。
</p>
<li>PL/Pythonの ビルド方法を決定するために、非推奨の distutils モジュールではなく、Python の sysconfig モジュールを使用するように configure が変更されました。  (Peter Eisentraut, Tom Lane, Andres Freund) (14)(13)(12)(11)(10)</li>
<p>
これにより Python 3.10 では distutils が非推奨になり Python 3.12 での削除が予定されている configure-time の警告が回避されます。 おそらく、Python 3.12 以降では configure --with-python は完全に失敗します。
</p>
<p>
sysconfig が Python 2.7 より前、また、Python 3.2 より前にも存在しなかったため、古くなった Python バージョンでの PL/Python のビルドはもはやできなくなります。
</p>
<li>OpenSSL なしでクロスコンパイルが再度可能となりました。  (Tom Lane) (14)</li>
<p>
configure ではターゲットシステムで /dev/urandom が使用可能であるはずと想定すべきでしたが、代わりに  configure が失敗していました。
</p>
<li>Windows 環境で Perl 5.28 以降を使用する PL/Perl コンパイルの失敗が修正されました。  (Victor Wagner) (14)(13)(12)(11)(10)</li>
<li>Python 3.11 以降での PL/Python コンパイルの失敗が修正されました。  (Peter Eisentraut) (14)(13)(12)(11)(10)</li>
<li>Visual Studio 2022 を使用したビルドがサポートされました。  (Hans Buschmann) (14)(13)(12)(11)(10)</li>
<li>MSVC ビルドシステムで .bat ラッパースクリプトを事前にディレクトリに移動することなく呼び出せるようになりました。  (Anton Voloshin, Andrew Dunstan) (14)(13)(12)(11)(10)</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 10.19 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/10-19/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Mon, 29 Nov 2021 00:58:20 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 10]]></category>
		<category><![CDATA[PostgreSQL 10.18]]></category>
		<category><![CDATA[PostgreSQL 10.19]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=7683</guid>

					<description><![CDATA[このリリースは 10.18 からの修正リリース（2021年11月11日リリース）です。 10.X からのアップデートではダンプ、リストアは不要です。 しかしながら、本リリースで修正されたいくつかの障害により既にインデック ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 10.18 からの修正リリース（2021年11月11日リリース）です。<br />
10.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、本リリースで修正されたいくつかの障害により既にインデックスに破損が生じている可能性があるため、該当するインデックスを再構築することが推奨されます。<br />
また、10.16 よりも前のバージョンから移行する場合には <a href="/tech-blog/pgsql/10-16">10.16 のリリース情報</a>も確認してください。</p>
<p><span id="more-7683"></span></p>
<h3>PostgreSQL 10.18 から 10.19 への変更点</h3>
<p>14.1、13.5、12.9、11.14、10.19、9.6.24 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>PostgreSQLサーバが SSL暗号化または GSS暗号化においてハンドシェイクが完了するまでは外来データを拒絶するようになりました。  (Tom Lane) (14)(13)(12)(11)(10)(9.6)</li>
<p>
これまで TCP接続にデータを挿入できる中間者は、暗号化で保護されているはずのデータベースセッションの冒頭に平文データを投入可能でした。サーバが認証データを要求してこない場合（例えば SSL証明書認証のみを使っている場合）に限られますが、これを悪用して偽の SQLコマンドをサーバに送ることができました。(CVE-2021-23214)
</p>
<li>libpq が SSL暗号化または GSS暗号化のハンドシェイクが完了する前は、外来データを拒絶するようになりました。  (Tom Lane) (14)(13)(12)(11)(10)(9.6)</li>
<p>
これまで TCP接続にデータを挿入できる中間者は、暗号化で保護されているはずのデータベースセッションの冒頭に平文データを投入可能でした。libpq の問い合わせ応答以外の細かい振る舞いのために実現は容易ではありませんが、これを悪用してクライアントの最初の問い合わせに偽の応答を挿入することがおそらく可能でした。別の攻撃は、セッションの初期に送られたクライアントのパスワードやその他の機微データを抜き出すことです。これは前項のサーバ側脆弱性と組み合わせて可能となります。(CVE-2021-23222)
</p>
<li>物理レプリケーションで、プライマリが部分的な WALレコードで終わっているWALセグメントを渡した後にクラッシュした場合について、修正されました。  (&Aacute;lvaro Herrera) (14)(13)(12)(11)(10)(9.6)</li>
<p>
ダウンするプライマリが不完全な WALレコードの残りを書き込み完了できなかった場合、以前のクラッシュリカバリロジックでは、それをバックアップして、不完全な WALレコードの最初から WAL を上書きしました。スタンバイサーバは既にその WALセグメントのコピーを持っているかもしれないので、これは問題がありました。不整合な次セグメントに遭遇して、手動の介入なしにはリカバリできないことになりました。
</p>
<p>
本障害により、更新処理を実行中のプライマリのクラッシュ後にスタンバイがレプリケーション継続できなくなる可能性があり、対処策はスタンバイで WALファイルを手動削除して再起動することでした。
</p>
<p>
クラッシュ後の再起動時に WALセグメント境界を越えたバックアップをしないように修正されました。その代わりに、次の WALセグメントの始めに新しいタイプ（OVERWRITE_CONTRECORD）の WALレコードを書いて、不完全な WALレコードは無視しなければならないことを知らせるようになりました。
</p>
<p>
この修正を適用する場合、新しい WALレコードタイプが生じるようになるため、プライマリより先にスタンバイサーバをアップデートするのが良いです。
</p>
<li>並列VACUUM がインデックスを取りこぼさないように修正されました。  (Peter Geoghegan, Masahiko Sawada) (14)</li>
<p>
テーブルが min_parallel_index_scan_size を上回る 2つ以上のインデックスを持つ場合に、並列VACUUM が min_parallel_index_scan_size を下回るインデックスを処理していませんでした。この結果、これらのインデックスは VACUUM で除去済みのヒープ上のエントリに対する参照を持つことになって、破損した状態となる可能性があります。
</p>
<p>
この問題は並列VACUUM を行わない autovacuum には影響しません。発生条件に該当する、サイズの大小が異なる複数のインデックスを持っていて手動VACUUM を行ったことがあるテーブルについて、REINDEX を行うことが推奨されます。
</p>
<li>CREATE INDEX CONCURRENTLY が直近の準備されたトランザクションを待つように修正されました。  (Andrey Borodin) (14)(13)(12)(11)(10)(9.6)</li>
<p>
準備されたトランザクションから直近に挿入された行が、新たなインデックスから無視されるかもしれませんでした。その結果、インデックスに依存する問い合わせが、その行を取りこぼすおそれがありました。
</p>
<p>
この問題に対する以前の修正は、CREATE INDEX CONCURRENTLY が検査したときに進行中の PREPARE TRANSACTIONコマンドを考慮できていませんでした。max_prepared_transactions &gt; 0 の準備されたトランザクション（二相コミット）が有効なサーバでは、CONCURRENTLY指定で作成されたインデックスを全て REINDEXすることが推奨されます。
</p>
<li>同時作成をしているインデックスで、新たな行に対するエントリ追加の失敗を引き起こす可能性のある競合状態が回避されました。  (Noah Misch, Andrey Borodin) (14)(13)(12)(11)(10)(9.6)</li>
<p>
これにより破損したインデックスが生じる可能性があります。実際には稀にしか発生しないとみられますが、この誤りは潜在的に CONCURRENTLY指定を付けたあらゆるインデックス構築または再構築に影響する可能性があります。同時作成したインデックスの全てを REINDEXすることが推奨されます。
</p>
<li>対象インデックスに付加された演算子クラスのパラメータを維持するようにREINDEX CONCURRENTLY が修正されました。  (Michael Paquier) (14)(13)</li>
<p>
REINDEX CONCURRENTLY 実行後にデフォルトパラメータになってしまう現象が発生していました。
</p>
<li>組込オブジェクト以外を含んだデータベースを複製するときの共有依存関係の誤作成が修正されました。  (Aleksander Alekseev) (14)</li>
<p>
データベースの複製は、テンプレートデータベースから新たなデータベースを作成するとき行われます。本誤動作の結果 pg_shdepend の内容が不正になります。原理的には本障害でオブジェクトを所有しているロールが削除可能になってしまう可能性がありますが、本障害の実際の影響は限定的と考えられます。
</p>
<li>パーティションテーブルにアタッチあるいはデタッチしているテーブルについて、リレーションキャッシュが確実に無効化されるようになりました。  (Amit Langote, &Aacute;lvaro Herrera) (14)(13)(12)(11)(10)</li>
<p>
本障害により、アタッチ/デタッチの後に既存のセッションからそのパーティションに対する直接の挿入/更新を行ったときに、アタッチ/デタッチ操作がリレーションキャッシュに反映されていないことによる、不適切な制約の適用等の誤動作を起こす可能性がありました。
</p>
<li>範囲型の作成時にパースツリーが破損する障害が、修正されました。  (Alex Kozhemyakin, Sergey Shinderuk) (14)</li>
<p>
CREATE TYPE がパースツリーの要素を誤って解放していて、続くイベントトリガや CREATE TYPE コマンドがプランキャッシュに格納されて後に再使用される場合に、（クラッシュや予期せぬエラー等の）問題が起きる可能性がありました。
</p>
<li>複合型のドメインの配列の要素の更新について修正されました。  (Tom Lane) (14)(13)(12)(11)</li>
<p>
「UPDATE tab SET fld[1].subfld = val」のようなコマンドが、配列要素が複合型ではなく複合型のドメインである場合に失敗して、クラッシュや誤った更新結果を引き起こしました。
</p>
<pre>
（障害発生例／クラッシュが生じる）
db=# CREATE TYPE typ11 AS (subfld1 int, subfld2 int);
db=# CREATE DOMAIN dom11 AS typ11 NOT NULL;
db=# CREATE TABLE tbl11 (id int, fld dom11[]);
db=# INSERT INTO tbl11 VALUES (1, '{"(1,2)","(3,4)"}'::dom11[]);
db=# UPDATE tbl11 SET fld[1].subfld1 = 1;
server closed the connection unexpectedly
</pre>
<li>FETCH FIRST WITH TIES と FOR UPDATE SKIP LOCKED の組み合わせが禁止されました。  (David Christensen) (14)(13)</li>
<p>
FETCH FIRST WITH TIES は同順位でない行を見つけるまで停止しないため、返すべき行数に加えてもう 1行を取り出す必要があります。また、現在の実装では FOR UPDATE が使われた場合は返さない行についてもロックを取得します。その結果、SKIP LOCKED オプションが指定された場合に望ましくない振る舞いが生じました。当面の対処として、この組み合わせが禁止されました。
</p>
<p>
以下の動作例では id=3 の行が応答に登場しない結果となります。
</p>
<pre>
（望ましくない動作の例）
db=# CREATE TABLE t12 (id int, n int);
db=# INSERT INTO t12 VALUES (1,10),(2,10),(3,30),(4,40);
db=# BEGIN;
     SELECT * FROM t12 ORDER BY n FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED;
 id | n
----+----
  1 | 10
  2 | 10
(2 rows)

（別セッションで以下を実行）
db=# SELECT * FROM t12 ORDER BY n FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED;
 id | n
----+----
  4 | 40
(1 row)
</pre>
<li>ALTER INDEX .. ALTER COLUMN .. SET (..) でのオプション指定が禁止されました。  (Nathan Bossart, Michael Paquier) (14)(13)</li>
<p>
これまでパーサが受け付けていて、ALTER TABLE の場合と同じパラメータが指定可能でしたが、これは文書記載がなく、実際には機能しない一方、オプションを付与するとその列やテーブルの削除ができなくなりました。
</p>
<li>numeric型の power() 関数で稀な場合の精度損失が修正されました。  (Dean Rasheed) (14)(13)(12)(11)(10)(9.6)</li>
<p>
第一引数が 1 に非常に近い場合に不正確な結果が生じる可能性がありました。「^」演算子の左辺が 1 に近い場合についても同様に該当します。
</p>
<li>Memoizeプランでハッシュ等価演算子の誤選択が回避されました。  (David Rowley) (14)</li>
<p>
本障害により、クラッシュまたは誤った問い合わせ結果が生じるおそれがありました。
</p>
<li>副問い合わせの式を関数にプルアップする際のプランナエラーが修正されました。  (Tom Lane) (14)(13)</li>
<p>
FROM にある関数が FROM句の副問い合わせの出力をラテラル参照する場合で、副問い合わせを外側の問い合わせに平坦化が可能である場合、関数の式へコピーされた式は完全には処理されませんでした。その結果、プランの実行時にクラッシュを引き起こすおそれがありました。
</p>
<pre>
（本障害でクラッシュを起こす問い合わせの例）
db=# SELECT * FROM (
       SELECT jsonb_path_query_array(mod-&gt;'lecs', '$[*]') AS lec
         FROM unnest(array['{"lecs": [{"id": "1"}]}'::jsonb]) AS um(mod)) AS ss,
           jsonb_to_recordset(ss.lec) AS j (id text);
</pre>
<li>列の範囲の見積に不完全な MCV のみのプランナ統計情報を信用して使わないように修正されました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
ANALYZE で稀に MCV（most-common-values、最頻値）リストが作られてヒストグラムは作られないことがあります。このような場合、MCVリストのみでデータ全体をあらわせそうな場合に限って、MCVリストのみで列値の範囲を見積をするようになりました。
</p>
<li>サブトランザクション内でのポータルのスナップショット復旧について修正されました。  (Bertrand Drouvot) (14)(13)(12)(11)</li>
<p>
プロシージャがあるトランザクションをコミットやロールバックして、その次の明示的な動作が新たなサブトランザクション内である場合にスナップショット管理を誤っていました。その結果、不正なポインタが生じて、クラッシュを引き起こす可能性がありました。
</p>
<p>
典型的には PL/pgSQL で以下のような処理を行う場合に該当します。
</p>
<pre>
  FOR i IN 1..100 LOOP -- 何らかのループ
    BEGIN 
      {問い合わせを実行}
    EXCEPTION
      {条件に応じて COMMIT や ROLLBACK を実行してループを継続}
    END;
  END LOOP;
</pre>
<li>スナップショットのエクスポート後にトランザクションが失敗した場合に、正しくクリーンアップするようになりました。  (Dilip Kumar) (14)(13)(12)(11)(10)(9.6)</li>
<p>
この誤りは、同じセッションがスナップショットを再びエクスポートしようとした場合に限って問題を引き起こします。ありそうな該当シナリオは、レプリケーションスロットを作成して、それが何らかエラーで失敗して、その後に続けて他のレプリケーションスロットを作成しようとすることです。
</p>
<p>
予期せぬ「ERROR:  clearing exported snapshot in wrong transaction state」が発生する動作が報告されました。
</p>
<li>スタンバイサーバでオーバーフローしたサブトランザクション追跡の周回を防止しました。  (Kyotaro Horiguchi, Alexander Korotkov) (14)(13)(12)(11)(10)(9.6)</li>
<p>
この誤りにより、スタンバイサーバで顕著な性能低下をもたらすおそれがあります。該当した場合、SubtransSLRU についての過大な処理量がはっきり現れました。
</p>
<li>スタンバイサーバの昇格中に、（二相コミット機能の）準備されたトランザクションが適切に考慮されるようになりました。  (Michael Paquier, Andres Freund) (14)(13)(12)(11)(10)(9.6)</li>
<p>
同時実行中のセッションが取得したスナップショットで、準備されたトランザクションが省略される可能性がある限られた時間帯がありました。その後、そのセッションがスナップショットを使用してデータを更新すると、誤った結果やデータの破損が発生する可能性がありました。
</p>
<li>EXPLAIN が WorkTableScanノードにアタッチされたフィルタ条件を表示しようとした時の予期せぬエラーが修正されました。  (Tom Lane) (14)</li>
<p>
CTE (WITH句）を伴う問い合わせの EXPLAIN で、以下のエラーが出る動作が報告されました。
</p>
<pre>
ERROR:  could not find RecursiveUnion for WorkTableScan with wtParam 0
</pre>
<li>ALTER INDEX コマンドを使ってテーブルの名前を変更する際に、正しいロックレベルを使用するように修正されました。  (Nathan Bossart, &Aacute;lvaro Herrera) (14)(13)(12)</li>
<p>
歴史的な理由から、ALTER INDEX ... RENAME はあらゆる種類のリレーションに適用できます。インデックス名を変更するのに必要なロックレベルは、テーブル等その他のリレーション名を変更する場合より低いのですが、ALTER INDEX を使った場合には対象がインデックス以外であっても、誤って低いロックレベルが使用されていました。
</p>
<pre>
（誤動作例）
db=# CREATE TABLE t24a (id int);  CREATE TABLE t24b (id int);
db=# BEGIN;
db=*# ALTER TABLE t24a RENAME TO t24x;
db=*# ALTER INDEX t24b RENAME TO t24y;
db=*# ^Z

（別セッションでロックを確認）
db=# SELECT relation::regclass, locktype, mode FROM pg_locks WHERE relation IS NOT NULL;
 relation | locktype |           mode
----------+----------+--------------------------
 pg_locks | relation | AccessShareLock
 t24b     | relation | ShareUpdateExclusiveLock
 t24a     | relation | AccessExclusiveLock
(3 rows)
</pre>
<li>オブジェクトとそのオブジェクトを所有するロールが並行して同時に削除された場合に null-pointer-dereference によるクラッシュが発生することがあり、回避されました。  (&Aacute;lvaro Herrera) (14)(13)(12)(11)(10)(9.6)</li>
<li>lo_export() または関連する関数が失敗した場合のスナップショット参照のリーク警告が防止されました。  (Heikki Linnakangas) (14)(13)(12)(11)(10)(9.6)</li>
<p>
以前は下記のようなメッセージが出力されましたが、実際のリークはほとんど害のないものでした。
</p>
<pre>
WARNING:  Snapshot reference leak: Snapshot 0x5634afd61cb8 still referenced
</pre>
<li>CoerceToDomain式ノードの非効率なコード生成が修正されました。  (Ranier Vilela) (14)(13)</li>
<p>
本修正は DOMEIN型の列に値を投入したり、DOMAIN型に型キャストする場合のエグゼキュータ処理を効率化します。
</p>
<li>いくつかのリスト操作で O(N^2) の動作が回避されるようになりました。  (Nathan Bossart, Tom Lane) (14)(13)</li>
<p>
これにより、 (1)プライマリ上で多数の排他ロックを保持しているトランザクションをスタンバイでリプレイする場合、 (2)チェックポイント後に削除(unlink)されることになっているファイルが多数ある場合、 (3)ハッシュ集約に多くのバッチ(ディスク書き出し)が含まれる場合、 (4)pg_trgm が複雑な正規表現からインデックス可能な条件を抽出する場合、を含むいくつかのシナリオで処理速度低下が修正されました。
</p>
<p>
これらのうち、実際にユーザから報告されたのは (1) だけですが、それ以外も非効率なリスト削除により該当すると見られます。
</p>
<li>B-tree のポスティングリスト分割に関する防御的な検査が追加されました。  (Peter Geoghegan) (14)(13)</li>
<p>
この変更により、テーブルの TID の重複を含むインデックスの破損を検出できるようになります。
</p>
<li>BRIN の float8 または float4 の minmax_multi_ops インデックスにNaN を挿入する時のアサート失敗が回避されました。  (Tomas Vondra) (14)</li>
<p>
アサートを無効にした実運用むけビルドにおいては、このような場合、いくらか非効率的ですが間違ってはいないインデックスになります。
</p>
<li>自動VACUUM のランチャープロセスが pg_log_backend_memory_contexts() の要求に対してより迅速に応答できるようになりました。  (Koyu Tanigawa) (14)</li>
<p>
これまで数秒を要することがありました。
</p>
<li>認証処理で使われる HMACハッシュ計算におけるメモリリークが修正されました。  (Sergey Shinderuk) (14)</li>
<li>shared_memory_type が sysv の場合、huge_pages を on に設定することが禁止されました。  (Thomas Munro) (14)(13)(12)</li>
<p>
以前はこの設定は受け入れられていましたが、実装がないため何もしませんでした。
</p>
<li>PL/pgSQL の RETURN QUERY文における、クエリ型のチェックが修正されました。  (Tom Lane) (14)</li>
<p>
RETURN QUERY は、UPDATE RETURNING のようにタプルを返すことができる任意のクエリを受け入れるべきです。 v14 では誤って SELECT 以外のものを禁止していました。さらに、可変の RETURN QUERY EXECUTE では、クエリ型チェックがまったく適用されていませんでした。
</p>
<li>大域的でないデフォルト権限を正しくダンプするように、pg_dump が修正されました。  (Neil Chen, Masahiko Sawada) (14)(13)(12)(11)(10)(9.6)</li>
<p>
大域的な（限定なしの）ALTER DEFAULT PRIVILEGES コマンドが関数の EXECUTE などデフォルトである権限を取り消した後、限定付きの ALTER DEFAULT PRIVILEGES コマンドが選択されたロールやスキーマに対してその権限を再び付与した場合、pg_dump は制限付きの権限付与を正しくダンプできませんでした。
</p>
<li>ダンプされるパーティションテーブルに対して、pg_dump が共有ロックを取得するようになりました。  (Tom Lane) (14)(13)(12)(11)(10)</li>
<p>
pg_dump が子のパーティションのいずれかをロックすれば、パーティションテーブル自体に対する重要な DDL を防ぐのに十分であるためこの見落としはたいていの場合は無害なものでしたが、関連するロックが保持されないため、子のないパーティションテーブルをダンプするときに問題が発生する可能性がありました。
</p>
<li>PostgreSQL 8.3 より前のサーバからトリガ定義をダンプしようとした際のpg_dump のクラッシュが修正されました。  (Tom Lane) (14)(13)(12)(11)</li>
<li>pg_restore の無効なラージオブジェクトの TOCファイルに関するエラーメッセージ中の誤ったファイル名が修正されました。  (Daniel Gustafsson) (14)(13)(12)(11)(10)(9.6)</li>
<p>
以前は以下のようなファイル名が空のエラーメッセージが表示されていました。
</p>
<pre>
pg_restore: error: invalid line in large object TOC file "": ..
</pre>
<li>ソケットレベルの障害発生後、pgbench がゼロ以外のステータスで終了するようになりました。  (Yugo Nagata, Fabien Coelho) (14)(13)(12)</li>
<p>
望ましい動作は実行を完了した後、ステータス 2 で終了することで、そのように修正されました。また、ソケットレベル障害のエラー報告が修正されました。
</p>
<li>pg_amcheck が一時的なリレーションや、無効または準備ができていないインデックスをチェックしないようにしました。  (Mark Dilger) (14)</li>
<p>
これにより、ほぼ確実に矛盾しているように見える、役に立たないリレーションのチェックが回避されます。
</p>
<li>contrib/amcheck がスタンバイサーバで実行される際に、UNLOGGEDテーブルをスキップするようになりました。  (Mark Dilger) (14)</li>
<p>
このようなテーブルは空になりますし、UNLOGGEDインデックスもすでにスキップするようになっているため、このようにするのが適切です。
</p>
<li>pg_stat_statements が最大 1GB 単位でクエリテキストファイルを読み込むようになりました。  (Tom Lane) (14)(13)(12)(11)(10)(9.6)</li>
<p>
2GB 以上のファイルを一度に読み込もうとするとすると失敗する可能性があるため、複数回に分けて読み込むようになりました。
</p>
<li>postgres_fdw がデータ変換エラーを報告しようとする際に発生しうる NULLポインタのクラッシュが修正されました。  (Tom Lane) (14)(13)(12)(11)(10)(9.6)</li>
<li>内部実装の関数 GetSharedSecurityLabel() が、クリティカルなリレーションキャッシュエントリがまだ構築されていない新たに開始したセッションでも使用できるようになりました。  (Jeff Davis) (14)(13)(12)(11)(10)(9.6)</li>
<p>
（サードパーティモジュール以外で）影響があるのは contrib/sepgsql のみです。
</p>
<li>TAPテストを実行する際、モジュール自体のディレクトリを PATH に含めるようになりました。  (Andrew Dunstan) (14)</li>
<p>
これによりインストールされていないプログラムを検出できるようになりました。
</p>
<li>Windows のタイムゾーン名を IANAタイムゾーンに割り当てるのにCLDRプロジェクトのデータを利用するようになりました。  (Tom Lane) (14)(13)(12)(11)(10)(9.6)</li>
<p>
initdb は新たなクラスタのタイムゾーンパラメータに、システムのタイムゾーンに対応した IANAタイムゾーンを設定しようとします。これまで Windows で利用していたマッピングテーブルは何年も前に生成され、更新も散発的にしか行われないため、エラーが含まれていたり、最近追加されたゾーンが存在していなかったりと問題がありました。既存インストレーションには影響はなく、新しく初期化されたデータベースクラスタにのみ影響します。
</p>
<li>タイムゾーンデータファイルが tzdata release 2021e に更新されました。   (14)(13)(12)(11)(10)(9.6)</li>
<p>
フィジー、ヨルダン、パレスチナ、サモアで夏時間法が変更され、バルバドス、クック諸島、ガイアナ、ニウエ、ポルトガル、トンガの歴史的修正が行われています。
</p>
<p>
また、Pacific/Enderbury は Pacific/Kanton に名称変更されました。また、Africa/Accra、America/Atikokan、America/Blanc-Sablon、America/Creston、America/Curacao、America/Nassau、America/Port_of_Spain、Antarctica/DumontDUrville、Antarctica/Syowa の各ゾーンは、近くのより人口の多いゾーンに統合されました。これらの名前はエイリアスとして残されています。
</p>
<li>float4 と float8 のハッシュ関数が NaN に対して均一の結果を生成するように修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
PostgreSQL は浮動小数点型は全ての NaN が等しいと見なすため、ハッシュ関数が IEEE 754 規格に従って NaN である全てのパターンに対して同じハッシュコードを生成することが重要です。今までそれができていなかったため、ハッシュインデックスやハッシュを伴った実行計画で、正規化されていない NaN値（'-NaN'::float8 など）に対して、誤った問い合わせ結果がもたらされるおそれがありました。
</p>
<p>
このような NaN値が含まれる可能性がある場合には、浮動小数点型の列に対するハッシュインデックスを再作成することが推奨されます。
</p>
<li>wal_level が minimal に設定されている時 CREATE TABLESPACE のクラッシュリカバリでのデータ損失が防止されました。  (Noah Misch) (13)(12)(11)(10)(9.6)</li>
<p>
CREATE TABLESPACE から次のチェックポイントまでの間にサーバがクラッシュした場合、クラッシュリカバリが実施されても完全にデータが復元されない可能性がありました。wal_level が minimal 以外の場合には該当しません。
</p>
<li>パーティションテーブルがパブリケーションへ追加もしくは削除される際に、全てのパーティションのリレーションキャッシュが無効化されるようになりました。  (Hou Zhijie, Vignesh C) (13)</li>
<p>
無効化が行われていなかったことによって、既存セッションでロジカルレプリケーションが誤動作を起こす可能性がありました。
</p>
<li>FOR ALL TABLES と指定されたパブリケーションを作成もしくは削除する際に、リレーションキャッシュが無効化されるようになりました。  (Hou Zhijie, Vignesh C) (13)(12)(11)(10)</li>
<p>
無効化が行われていなかったことによって、既存セッションでロジカルレプリケーションが誤動作を起こす可能性がありました。
</p>
<li>修飾子が指定されていない同じ型へのキャストを破棄しないようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
例えば、numeric(18,3) と定義されている f1列の場合、パーサは f1::numeric の様なキャストを実行時には影響がないという理由で破棄していました。しかし、外側にあらわれる型は、numeric(18,3) ではなく numeric であるべきです。これは再帰的な UNION など、より大きな構造の型を正しく解決するために重要です。
</p>
<pre>
（ビュー定義で型キャストが無視される誤動作例）
db=# CREATE TABLE t51 (f1 numeric(18, 3));
db=# CREATE VIEW v51 AS SELECT f1::numeric AS n1 FROM t51;
db=# \d+ v51
                                View "public.v51"
 Column |     Type      | Collation | Nullable | Default | Storage | Description
--------+---------------+-----------+----------+---------+---------+-------------
 n1     | numeric(18,3) |           |          |         | main    |
View definition:
 SELECT t51.f1 AS n1
   FROM t51;
</pre>
<p>
旧動作が誤っていると考えられますが、非互換性を含む修正となります。
</p>
<li>現在のデータベースエンコーディングがサポートしていない ICU照合順序は作成できないようになりました。  (Tom Lane) (13)(12)(11)(10)</li>
<p>
これまでは作成はできていましたが、実際には照合順序は使用できず、削除することもできない状態となっていました。
</p>
<li>{0} 内の括弧をキャプチャする際の正規表現エラーを回避するようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
(.){0}...\1 の様な正規表現において、間違った後方参照番号が引き出され、下記のようなエラーやクラッシュ、アサート失敗が生じる可能性がありました。エラーを発生させずに後方参照がマッチしないと判断するように修正されました。
</p>
<pre>
ERROR:  invalid regular expression: invalid backreference number
ERROR:  invalid regular expression: quantifier operand invalid
</pre>
<li>正規表現の後方参照が、本来マッチすべきでない時にマッチしてしまうのを防ぐようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
正規表現エンジンは部分的なマッチを拒否した後のキャプチャした括弧のマッチデータ排除に関して不注意でした。これにより、定義された参照先がないために失敗するはずの場所で、後方参照が一致する可能性がありました。
</p>
<pre>
（誤動作例）
db=# select 'abcdef' ~ '^(.)\1|\1.';
 ?column?
----------
 t
(1 row)

（先頭で同文字が連続していないので部分マッチせず、全体としても f になるのが正しい）
</pre>
<li>反復ノード内の後方参照による正規表現の性能上のバグが修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
後方参照のロジックが正しくなく、必要以上に時間を要する箇所がありました。幸いなことに、この問題はほとんどの場合に他の最適化によって顕在化することがありませんでした。
</p>
<li>タイムゾーン付きの時刻を AT TIME ZONE に適用した際に、間違った結果を返す問題が修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
動的な TZ 略語でゾーンが指定されている場合に誤った問い合わせ結果が生じる可能性があります。
</p>
<pre>
（報告された誤動作例、CLT は -03 または夏時間で -04）
db=# SELECT '12:34 -02'::timetz AT TIME ZONE 'CLT';
     timezone
-------------------
 09:51:14-04:42:46
(1 row)
</pre>
<li>PlaceHolderVars の継承子テーブルへの転換の誤りが修正されました。  (Tom Lane) (13)(12)</li>
<p>
PlaceHolderVars は内部実装上のデータ構造です。この誤りにより、パーティションテーブルや継承テーブルを外部結合の外側（無ければ NULL になる側）に持つ問い合わせで、アサート失敗や実行計画の異常が生じる可能性がありました。実際の問題発生は稀であると考えられます。
</p>
<li>バックグラウンドワーカが LISTEN を実行できないようになりました。  (Tom Lane) (13)</li>
<p>
実行するための基盤が無いため、実行されてしまうと単に NOTIFY によるキューのクリーンアップを妨げる結果となります。
</p>
<li>他のバックエンドへの NOTIFY シグナル送信をトランザクションコミットの時に行うようになりました。  (Artur Zakirov, Tom Lane) (13)</li>
<p>
この変更によってプロシージャ内の COMMIT 直後に通知を送信できるようになりました。また、ロジカルレプリケーションワーカが通知を送信できるようになりました。これまではアイドル状態にならないと送信されず、これらのことができませんでした。
</p>
<li>WITH HOLD オプションによって前トランザクションから保留されている NO SCROLL指定のカーソルの巻き戻しを、拒否するようになりました。  (Tom Lane) (13)(12)(11)</li>
<p>
長い間 NO SCROLL カーソルを逆方向にフェッチすることは禁止されていましたが、歴史的背景により、クエリを完全に巻き戻してから再度フェッチすることは禁止されていませんでした。この例外は、特に巻き戻しに必要なデータを全て保持していない可能性のある保留されたカーソルの場合には不整合を引き起こしました（クラッシュが報告されています）。最悪のケースを防ぐためにスクロールできない保留されたカーソルの巻き戻しを禁止するようになりました。
</p>
<p>
非互換性を含む修正となります。
</p>
<li>WITH HOLD カーソルをトランザクション終了時点で保存するときに、既にカーソルが読み込み完了していた場合に、失敗しないように修正されました。  (Tom Lane) (13)(12)(11)</li>
<p>
クラッシュが生じる動作が報告されました。
</p>
<li>許可された最大長に増大したリレーションの検出が修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
これまでも 2^32 - 1 ブロックという最大長を超えてテーブルやインデックスを拡張する試みはストレージ処理の段階で拒絶されました。しかし、不整合な内部状態を防ぐにはより早い検知が必要で、バッファマネージャにおいてエラーを出すようになりました。
</p>
<p>
アサート失敗が報告されました。
</p>
<li>DO INSTEADルールを展開するときに、データ変更を伴う CTE（WITH句）の存在を確認するようになりました。  (Greg Nancarrow, Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
これが行われなったため、安全でないパラレルプラン選択などの問題が生じるおそれがありました。ルールが適用される問い合わせの実行時に「ERROR:  cannot assign XIDs during a parallel operation」が生じる動作が報告されました。
</p>
<p>
これからは、データ変更を伴う CTE を持つ問い合わせには DO INSTEDルールの適用はできず、そのことを示すエラーになります。
</p>
<pre>
（修正後の振る舞い例）
db=# CREATE TABLE t63a (i int);
db=# CREATE TABLE t63b (i int);
db=# CREATE RULE r63a AS ON INSERT TO t63a DO INSTEAD
       INSERT INTO t63b SELECT NEW.i;
db=# WITH cte1 AS (DELETE FROM t63a RETURNING *)
       INSERT INTO t63a SELECT * FROM cte1;
ERROR:  INSERT...SELECT rule actions are not supported for queries having data-modifying statements in WITH
</pre>
<li>拡張統計情報オブジェクトへの権限のない操作に対する誤ったパーミッションエラー報告が修正されました。  (Tomas Vondra) (13)(12)(11)(10)</li>
<p>
以前は意図したメッセージではなく以下のようなキャッシュルックアップエラーが出力されていました。
</p>
<pre>
ERROR:  cache lookup failed for type 27447
</pre>
<li>並列ワーカの誤ったスナップショット処理が修正されました。  (Greg Nancarrow) (13)(12)(11)(10)</li>
<p>
以前はトランザクション分離レベルが REPEATABLE READ よりも低かった場合、パラレルクエリで誤動作をすることがありました。
</p>
<p>
アサート失敗が報告されました。
</p>
<li>一時テーブルの TOASTテーブル変更を適切に無視するように、ロジカルデコーディングが修正されました  (Bertrand Drouvot) (13)(12)(11)</li>
<p>
ロジカルデコーディングは、ALTER TABLE によるヒープ書き換えなどで作られる一時テーブルの変更を通常は無視しますが、関連する TOASTテーブルについてそのようになっていませんでした。
</p>
<p>
これにより、パブリッシュされたテーブルを ALTER TABLE すると、その後で予期せぬエラーが生じることがありました。
</p>
<li>TOASTデータを正しく処理するために論理デコーディングのメモリ使用量計算が修正されました。  (Bertrand Drouvot) (13)</li>
<p>
アサート失敗やクラッシュを引き起こす可能性がありました。
</p>
<li>walreceiverプロセスが、終了する前に全ての必要なアーカイブ通知ファイルを 作成するのを保証するようになりました．  (Fujii Masao) (13)(12)(11)(10)(9.6)</li>
<p>
通知ファイルとは archive_status ディレクトリ下に作られる.ready や .done のサフィックスを持ったファイルです。
</p>
<p>
これまで walreceiver はちょうど WALセグメント境界で終了した場合、最後に受信したセグメントの通知ファイル作成に失敗していました。その結果、スタンバイでセグメントをアーカイブするのが遅れていました．
</p>
<li>バックアップマニフェスト生成における WAL範囲の計算が、タイムライン変更が伴う場合について修正されました。  (Kyotaro Horiguchi) (13)</li>
<p>
昇格直後のベースバックアップがpg_veryfybackup で失敗するケースが報告されていました。
</p>
<li>SELECT .. FOR UPDATE を使うルールで疑似リレーション OLD、NEW にロック処理を行わないように修正されました。  (Masahiko Sawada, Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
OLD や NEW を指定して SELECT .. FOR UPDATE を行うルールの実行で予期せぬエラーやクラッシュが生じていました。
</p>
<li>集約の FILTER句のパーサ処理が修正されました．  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
FILTER式が単純な boolean型の列の場合に、誤った意味解釈が行われて仕様外の動作（即ち、誤った問い合わせ結果）が生じる可能性がありました。また、FILTER式自体が boolean型を返す集約である場合にはエラーを出すべきですが、そのようになっておらず、実行時にクラッシュを起こすことがありました。
</p>
<pre>
（修正前バージョンでの障害発生例）
db=# CREATE TABLE t71 (i int, b boolean);
db=# INSERT INTO t71 VALUES (1, 't'),(2, 't'), (3, 'f');
db=# SELECT (SELECT max(0) FILTER (WHERE b IS TRUE)) FROM t71;
 max
-----
   0
(1 row)

db=# SELECT (SELECT max(0) FILTER (WHERE b)) FROM t71; -- 誤動作する
 max
-----
   0
   0

(3 rows)

db=# SELECT (SELECT array_agg(z.b) FILTER (WHERE bool_or(z.i &gt; 0))
       FROM t71) FROM t71 z; -- クラッシュする
server closed the connection unexpectedly
</pre>
<li>ALTER TYPE/DOMAIN/OPERATOR .. SET が拡張のメンバシップを変更しないように修正されました。  (Tom Lane) (13)</li>
<p>
拡張のスクリプトで実行された ALTER .. SET は、ターゲットとなるオブジェクトが拡張のメンバになっていなかった場合に、それを拡張のメンバにしてしまうことがありました。
</p>
<p>
拡張のスクリプトがその拡張に属さないオブジェクトにアクセスする理由はほとんど無いため、これ自体は大きな問題はありません。しかし、ALTER TYPE .. SET はその型に依存するドメインにも再帰的に効果を及ぼすため、それらも拡張のメンバになり、拡張のアップグレードスクリプトで望まない副作用を引き起こしました。
</p>
<li>LLVM 内でのエラー後に LLVM状態のクリーンアップを試みないように修正されました。  (Andres Freund, Justin Pryzby) (13)(12)(11)</li>
<p>
これにより、致命的な LLVM のエラーが起きた後にバックエンドが終了する際に起こりうるクラッシュを防止します．
</p>
<li>SP-GiSTインデックスのスキャンが統計ビューでカウントされることを保証するようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
SP-GiST のコードでは、タプルのカウンタは正しく進む一方で、インデックススキャン回数の加算が欠落していました。
</p>
<li>リカバリ中に recovery_min_apply_delay が変更された場合には、関連する待機間隔を再計算するようになりました。  (Soumyadeep Chakraborty, Ashwin Agrawal) (13)(12)(11)(10)(9.6)</li>
<p>
これにより設定変更が直ぐに効くようになります。
</p>
<li>simplehash.h のハッシュテーブルが 2^32 要素を超えた場合に無限ループになる誤りを修正しました．  (Yura Sokolov) (13)(12)(11)(10)</li>
<p>
これは数百GB の work_mem が設定されていない限り顕在化しないため、実際には発生していなかったものと見られます。
</p>
<li>ANALYZE実行における拡張統計の計算中のメモリ使用量が削除されました。  (Justin Pryzby, Tomas Vondra) (13)(12)(11)(10)</li>
<li>AIX において libpq の関数が欠落しており、修正されました。  (Tony Reix) (13)</li>
<p>
コード再編成の誤りで以下のドキュメント記載された関数がエクスポートされていませんでした。
</p>
<pre>
  pg_encoding_to_char()
  pg_utf_mblen()
  pg_char_to_encoding()
  pg_valid_server_encoding()
  pg_valid_server_encoding_id()
</pre>
<li>接続を試みている途中で malloc() に失敗してもエラー後に正しく回復できるように、ecpg が修正されました。  (Michael Paquier) (13)(12)(11)(10)(9.6)</li>
<p>
ecpg を使うクライアントで pthread の mutex が残ったままになっていて、リソースリークやデッドロックを起こす恐れがありました。
</p>
<li>PL/pgSQL の CALL文の引数で呼ばれる STABLE の関数を誤って評価していたものが修正されました。  (Tom Lane) (13)(12)(11)</li>
<p>
静的関数は古いスナップショットを使って呼ばれており、そのため、セッションのトップレベルコマンドの開始後に行われたデータベースの変更が見えていませんでした。
</p>
<li>PL/pgSQL で最も外側のブロックからの EXIT が可能になりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
明示的な RETURN を必要としないルーチンであれば、この使い方は有効でしたが、これまでは許されていませんでした。
</p>
<li>pg_ctl のハードコーディングされた生成されたコマンド長の上限が取り除かれました。  (Phil Krylov) (13)(12)(11)(10)(9.6)</li>
<p>
これにより、例えば postmaster に渡すコマンドラインオプションを多数指定する場合の制限がなくなります。なお、pg_ctl が扱うパス名についての制限は未だあり、殆どの場合 MAXPGPATH（デフォルト1024）バイトで制限されます。
</p>
<li>RLS（行単位セキュリティ）ポリシーむけにテーブルごとの問い合わせ作成を回避することで、また、反復的な format_type() の呼び出しを回避することで、pg_dump の性能が改善されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
これらの変更はローカルサーバからのダンプでは重要ではありませんが、リモートサーバからのダンプではネットワーク往復が少なくなることで顕著なメリットがあります。
</p>
<li>contrib/btree_gin の（char(n)ではなく）"char" 列に対するインデックスの誤りが修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
&lt; や &lt;= 演算子を使ったインデックススキャンが実行されたときに、誤った問い合わせ結果（返るべきエントリが返らない）が生じました。インデックス破損ではなく、検索ロジックの誤りに起因します。
</p>
<li>RISC-V アーキテクチャむけのスピンロックのサポートが追加されました。  (Marek Szuba) (13)(12)(11)(10)(9.6)</li>
<li>OpenSSL 3.0.0 がサポートされました。  (Peter Eisentraut, Daniel Gustafsson, Michael Paquier) (13)(12)(11)(10)</li>
<li>作成した OpenSSL の BIO（I/O 抽象化）オブジェクトに正しい型識別子を設定するようになりました。  (Itamar Gafni) (13)(12)(11)(10)(9.6)</li>
<p>
この誤りは、おそらく OpenSSL のインストールを監査する類のタスクを行うコードでのみ問題となります。しかし、形としては OpenSSL API に違反しているため修正されました。
</p>
<li>libpq の静的リンクのための pkg-configファイルが修正されました。  (Peter Eisentraut) (13)(12)</li>
<p>
PostgreSQL 12 以降から、長らく正しい pkg-configファイルが提供されていませんでした。
</p>
<li>pg_regexec() が範囲外の search_start パラメータに対してより頑健になりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
pg_regexec() は PostgreSQL の正規表現機能の内部実装関数です。
</p>
<p>
search_start が文字列の終わりを過ぎている場合に、これまではクラッシュの可能性がありましたが、REG_NOMATCH を返すようになります。この場合はおそらく PostgreSQLコアコードでは生じませんが、拡張モジュールから使われるかもしれません。
</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 10.18 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/10-18/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Wed, 01 Sep 2021 02:02:08 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 10]]></category>
		<category><![CDATA[PostgreSQL 10.17]]></category>
		<category><![CDATA[PostgreSQL 10.18]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=7244</guid>

					<description><![CDATA[このリリースは 10.17 からの修正リリース（2021年8月12日リリース）です。 10.X からのアップデートではダンプ、リストアは不要です。 しかしながら、10.16 よりも前のバージョンから移行する場合には 10 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 10.17 からの修正リリース（2021年8月12日リリース）です。<br />
10.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、10.16 よりも前のバージョンから移行する場合には <a href="/tech-blog/pgsql/10-16">10.16 のリリース情報</a>も確認してください。</p>
<p><span id="more-7244"></span></p>
<h3>PostgreSQL 10.17 から 10.18 への変更点</h3>
<p>13.4、12.8、11.13、10.18、9.6.23 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>射影ステップの繰り返し適用による誤った実行計画の作成が修正されました。  (Tom Lane) (13)(12)(11)</li>
<p>
2つの ProjectionPath（射影、ターゲットリストの処理を行うパス）が互いにスタックした場合、プランナが誤った実行計画を作成する可能性がありました。これを再現させる既知の手順は並列ソートのみですが、それ以外の発生パターンもあるかもしれません。本障害によりクラッシュまたは誤った問い合わせ結果が生じます。また、障害動作を狙って起こしてサーバのメモリ内容の漏洩を狙う攻撃も可能です。(CVE-2021-3677)
</p>
<p>
以下に再現例を示します。
</p>
<pre>
db=# CREATE TABLE t1 (c1 int, c2 int);
db=# INSERT INTO t1 VALUES (1, 2), (3, 4);
db=# SET parallel_setup_cost TO 0;
db=# SET parallel_tuple_cost TO 0;
db=# SET min_parallel_table_scan_size TO 0;
db=# SET max_parallel_workers_per_gather TO 4;

db=# SELECT generate_series(1, c1), array(SELECT generate_series(1, c1)) FROM t1 ORDER BY c2;
（修正前の誤った問い合わせ結果）
 generate_series |   array
-----------------+-----------
               1 | {1,2}
               2 | {1,2}
               1 | {1,2,3,4}
               2 | {1,2,3,4}
               3 | {1,2,3,4}
               4 | {1,2,3,4}
(6 rows)

（修正後の正しい応答）
 generate_series |  array
-----------------+---------
               1 | {1}
               1 | {1,2,3}
               2 | {1,2,3}
               3 | {1,2,3}
(4 rows)

（修正前の誤ったプラン、一部で c1列と c2列が取り違えられている）
db=# EXPLAIN (VERBOSE, COSTS off)
       SELECT generate_series(1, c1), array(SELECT generate_series(1, c1)) FROM t1 ORDER BY c2;
                      QUERY PLAN
-------------------------------------------------------
 ProjectSet
   Output: generate_series(1, t1.c2), (SubPlan 1), t1.c1
   -&gt;  Gather Merge
         Output: t1.c2, t1.c1
         Workers Planned: 3
         -&gt;  Sort
               Output: t1.c2, t1.c1
               Sort Key: t1.c2
               -&gt;  Parallel Seq Scan on public.t1
                     Output: t1.c2, t1.c1
   SubPlan 1
     -&gt;  ProjectSet
           Output: generate_series(1, t1.c2)
           -&gt;  Result
(14 rows)
</pre>
<li>SSL再ネゴシエーションがより完全に禁止されました。  (Michael Paquier) (13)(12)(11)(10)(9.6)</li>
<p>
SSL再ネゴシエーションはしばらく前から無効になっていましたが、クライアイントから再ネゴシエーションの要求があれば受けつけてしまい、悪意の狙って作られた要求によりクラッシュを起こすおそれがありました（OpenSSL の脆弱性 CVE-2021-3449 を参照）。OpenSSL 1.1.0h 以降のそれが可能なバージョンについて、再ネゴシエーションが完全に無効化されました。
</p>
<li>プロシージャ内の COMMIT または ROLLBACK の後にポータルレベルのスナップショットを復元するようになりました。  (Tom Lane) (13)(12)(11)</li>
<p>
この変更により、COMMIT または ROLLBACK の直後に TOAST化された値を取得しようとし、「no known snapshots」または「missing chunk number 0 for toast value」のエラーとなる場合が修正されます。
</p>
<p>
一部の拡張はポータル外で SQL を実行するかもしれません。このような拡張は事前に外部スナップショットの存在確認をする必要があります。以前はスナップショットを存在せずとも動作する場合もありましたが、今後は「cannot execute SQL without an outer snapshot or portal」のエラーとなります。
</p>
<pre>
（修正前の障害動作例）
db=# CREATE TABLE t3 (c text);
db=# INSERT INTO t3 VALUES ((SELECT string_agg(random()::text, ':') FROM generate_series(1, 1000)));
db=# INSERT INTO t3 VALUES ((SELECT string_agg(random()::text, ':') FROM generate_series(1, 1000)));
db=# DO $$
     DECLARE
       r record;
     BEGIN
       FOR r in SELECT c FROM t3 LOOP
         INSERT INTO t3 VALUES (r.c);
         COMMIT;
       END LOOP;
     END;
     $$;
ERROR:  no known snapshots
CONTEXT:  PL/pgSQL function inline_code_block line 5 at FOR over SELECT rows
</pre>
<li>不安定なクエリを読み取るカーソルの結果を保持する際の誤った動作が修正されました。  (Tom Lane) (13)(12)(11)</li>
<p>
以前は、クエリ結果全体を常に巻き戻して再読み取りしていましたが、行を再度取り出した際に以前とは異なる結果となる可能性があり、あとで大きな問題となっていました。NO SCROLL指定のカーソルは順序どおりにしか行を取り出せないため、読み取っていない部分のみを保持することで修正されました。SCROLL指定のカーソルは問題が残ったままですが、不安定なクエリで使用するのは安全でないことがすでにマニュアルに記述されています。そこで、その記述をより強調することで対処されました。
</p>
<p>
また、PL/pgSQL のクエリ結果による FORループで使用される暗黙カーソルに NO SCROLL指定を強制し、プロシージャ内のコミットでそのようなカーソルを保持する際の同様の問題が修正されました。
</p>
<pre>
（修正前の誤った問い合わせ結果の例）
db=# CREATE TABLE t4 (c1 int, c2 text);
db=# INSERT INTO t4 VALUES (1, 'foo'), (2, 'bar'), (3, 'baz');
db=# DO $$
     DECLARE
       c CURSOR FOR SELECT c1 FROM t4 ORDER BY c1 FOR UPDATE;
     BEGIN
       FOR r IN c LOOP
         UPDATE t4 SET c2 = c2 || ' ' || c2 WHERE c1 = r.c1;
         COMMIT;
       END LOOP;
     END;
     $$;

db=# SELECT * FROM t4;
 c1 |   c2
----+---------
  2 | bar
  1 | foo foo
  3 | baz baz
(3 rows)

(修正後の正しい結果)
 c1 |   c2
----+---------
  1 | foo foo
  2 | bar bar
  3 | baz baz
(3 rows)
</pre>
<li>SELECT ... GROUP BY GROUPING SETS (()) FOR UPDATE が拒否されるようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
グループ化セットなしの GROUP BY と同様に FOR UPDATE は拒否すべきですが、以前は、空のグループ化セットを正しく処理できず、エグゼキュータでクラッシュしていました。
</p>
<pre>
（修正前のクラッシュする問い合わせ例）
db=# SELECT NULL FROM t1 GROUP BY GROUPING SETS (()) FOR UPDATE;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

(修正後)
db=# SELECT NULL FROM t1 GROUP BY GROUPING SETS (()) FOR UPDATE;
ERROR:  FOR UPDATE is not allowed with GROUP BY clause
</pre>
<li>WITH 内のクエリが NOTIFY のみに書き換えられる場合を拒否するようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
以前はクラッシュしていました。
</p>
<pre>
（修正前のクラッシュ発生例）
db=# CREATE RULE r AS ON INSERT TO t DO INSTEAD NOTIFY n;
db=# WITH w AS (INSERT INTO t VALUES (0)) VALUES (0);
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

（修正後は以下のエラーが出ます）
ERROR:  DO INSTEAD NOTIFY rules are not supported for data-modifying statements in WITH
</pre>
<li>結果が小数点以下 16383 桁を越える乗算をした場合にエラーとせずに結果を丸めるようになりました。  (Dean Rasheed) (13)(12)(11)(10)(9.6)</li>
<pre>
（修正前の動作）
db=# SELECT (0.1 - 2e-16383) * (0.1 - 3e-16383);
ERROR:  value overflows numeric format

（修正後の応答）
                                   ?column?
-------------------------------------------------------------------------------
 0.010000000000000000000000000000000(中略)000000000000000000000000000000000000
(1 row)
</pre>
<li>非常に大きな累乗をした際のごく稀なエラーと精度の低下が修正されました。  (Dean Rasheed) (13)(12)(11)(10)(9.6)</li>
<pre>
（修正前の誤動作例：エラーになる場合）
db=# SELECT 0.9999999999 ^ 70000000000000;
ERROR:  value overflows numeric format

（修正前の誤動作例：誤った問い合わせ結果が返る場合）
db=# SELECT 0.9999999999 ^ 23300000000000;
                                   ?column?
-------------------------------------------------------------------------------
 1.000000000000000000000000000000000...中略...000000000000000000000000000000000
(1 row)
</pre>
<li>to_char() に EEEE書式で 10 ^ (-10001) 未満の値を与えた場合のゼロ除算エラーが修正されました。  (Dean Rasheed) (13)(12)(11)(10)(9.6)</li>
<pre>
（障害動作例）
db=# SELECT to_char(1.2345e-16379::numeric, '9.999EEEE');
ERROR:  division by zero

（修正後の正しい応答）
     to_char
---------------
  1.235e-16379
(1 row)
</pre>
<li>pg_size_pretty(bigint) が numeric版と同様に正の値と同じ方法で負の値を丸めるように修正されました。  (Dean Rasheed, David Rowley) (13)(12)(11)(10)(9.6)</li>
<pre>
（正の値の応答）
db=# SELECT pg_size_pretty(10485247::bigint);
 pg_size_pretty
----------------
 10239 kB
(1 row)

（負の値に対する障害動作）
db=# SELECT pg_size_pretty(-10485247::bigint);
 pg_size_pretty
----------------
 -10 MB
(1 row)

（修正後の正しい応答）
 pg_size_pretty
----------------
 -10239 kB
(1 行)
</pre>
<li>pg_filenode_relation(0, 0) がエラーを出すのではなく NULL を返すようになりました。  (Justin Pryzby) (13)(12)(11)(10)(9.6)</li>
<p>
無効なテーブル空間の OID とファイルノード番号に対しては NULL を返すべきですが、以前は 0 を与えた場合に紛らわしいエラーとなっていました。
</p>
<pre>
（修正前のエラー応答）
db=# SELECT pg_filenode_relation(0, 0);
ERROR:  unexpected duplicate for tablespace 0, relfilenode 0
</pre>
<li>ALTER EXTENSION が拡張にオブジェクトを追加または削除する際に、ロックを取得するようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
以前は ALTER EXTENSION ADD/DROP と DROP EXTENSION が同時に実行できて、その結果、システムカタログを破損する可能性がありました。
</p>
<li>ALTER SUBSCRIPTION が空文字列のスロット名を拒絶するように修正されました。  (Japin Li) (13)(12)(11)(10)</li>
<pre>
（修正後のエラーが返る動作）
db=# ALTER SUBSCRIPTION s SET (slot_name = '');
ERROR:  replication slot name "" is too short
</pre>
<li>パーティションテーブルのトリガを新たなパーティションに複製するときに、トリガの有効/無効ステータスを確実にコピーするようになりました。  (&Aacute;lvaro Herrera) (13)(12)(11)</li>
<p>
これまではパーティションテーブルのトリガのステータスが、子テーブルに伝搬しませんでした。
</p>
<li>REFRESH MATERIALIZED VIEW CONCURRENTLY むけに生成された問い合わせで、別名の衝突を回避するようになりました。  (Tom Lane, Bharath Rupireddy) (13)(12)(11)(10)(9.6)</li>
<p>
mv と newdata など、特定の名前の列を含むマテリアライズドビューでコマンドが失敗していました。「ERROR: column reference "mv" is ambiguous」といったエラーが発生しました。
</p>
<li>PREPARE TRANSACTION がセッション寿命のロックとトランザクション寿命のロックの衝突を正しく検査するように修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
同じ勧告的ロックID値に対してセッション寿命とトランザクション寿命の両方のロックを持っている場合、トラザクションは準備された状態にできません。この制限は完全には検査されておらず、PREPARE TRANSACTION 実行時に PANIC を引き起こすおそれがありました。
</p>
<li>RLS（行単位セキュリティ）のポリシーに複数回リストされているロールをターゲットにした DROP OWNED BY の誤動作が修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
そのような場合、アサート失敗や「ERROR:  tuple already updated by self」が引き起こされました。
</p>
<li>DROP OWNED BY 実行中に RLS ポリシーからロールを削除する際の不要なエラーチェックが削除されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
特に、DROP OWNED BY を使うのにスーパーユーザであることを必須とする場合について、修正されています。
</p>
<li>CREATE COLLATION にて古い形式の Windowsロケール名を許容するようになりました。  (Thomas Munro) (13)</li>
<p>
ある時点から、古い形式のロケールに対して OS がバージョン情報を提供できないためにエラーにしていましたが、そのようなロケールを再度許容するようになりました。
</p>
<pre>
（13.3 バージョンでエラーになる例）
db=# CREATE COLLATION public.ja_jp (LOCALE = 'Japanese_Japan.932');
ERROR:  could not get collation version for locale "Japanese_Japan.932":
error code 87
</pre>
<li>行全体の変数を GENERATED句で利用できなくなりました。  (Tom Lane) (13)(12)</li>
<p>
GENERATED句で行全体の変数を利用することは、生成列がそれ自体もしくは他の生成列を参照できないというルールに違反しており、そのようなケースの動作が明白に定義されていませんでした。実際の動作としては、しばしばクラッシュを引き起こしました。
</p>
<pre>
（GENERATED句に行全体の変数を使用する例）
db=# CREATE TABLE t20 
       (a int PRIMARY KEY, b int GENERATED ALWAYS AS (num_nulls(t20)) STORED);
ERROR:  cannot use whole-row variable in column generation expression
</pre>
<li>GENERATED の式における tableoid の使用について修正されました。  (Tom Lane) (13)(12)</li>
<p>
システム列 tableoid に対して 0 や誤った値が取得される場合がありました。ALTER TABLE で後から生成列を加えた場合や、生成列を持つ外部テーブルにINSERT や UPDATE を行う時に誤動作が発生します。
</p>
<li>外部テーブルに対して高速デフォルトをセットしないようになりました。  (Andrew Dunstan) (13)(12)(11)</li>
<p>
外部テーブルのようにローカルにヒープストレージが存在しない場合、高速デフォルトは役に立たず、その後の操作で混乱が生まれます。バージョン11 で高速デフォルトが追加された際に対象のテーブルが通常テーブルであるかのチェックがなかったため追加されました。
</p>
<li>インデックス状態フラグをトランザクションとして更新できるようになりました。  (Michael Paquier, Andrey Lepikhov) (13)(12)(11)(10)(9.6)</li>
<p>
これにより、インデックス述部が IMMUTABLE と宣言されているけれども実際にはそうではない場合の処理で失敗するのを回避できます。CREATE INDEX CONCURRENTLY でアサート失敗が生じるケースが報告されました。
</p>
<li>CREATE/ALTER DOMAIN がキャッシュされた実行プランにあらわれたときに、プランのキャッシュエントリが破損しないようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
プリペアドステートメントとして、これら命令を実行したときに、「ERROR:  unrecognized node type: N」(Nは数値）という予期せぬエラーが生じるケースが報告されました。
</p>
<li>pg_stat_activity にて walsender の最新のレプリケーションコマンドが表示されるようになりました。  (Tom Lane) (13)(12)(11)(10)</li>
<p>
今までは最新の SQL コマンドが表示されており、実際には表示されている SQL コマンドではなくレプリケーションコマンドが実行されている場合に紛らわしいものとなっていました。
</p>
<li>postgresql.conf から設定項目が削除された場合でもpg_settings.pending_restart　が true にセットされるようになりました。  (&Aacute;lvaro Herrera) (13)(12)(11)(10)(9.6)</li>
<p>
pending_restart は再起動が必要な設定項目が変更された際は正しく表示されていましたが、設定項目自体が削除された場合に対応できていませんでした。
</p>
<li>64 ビットの Windows で work_mem × hash_mem_multiplier が 2GB を超えることが許容されました。  (Tom Lane) (13)</li>
<p>
これにより hash_mem_multiplier を数ギガバイトを超えるような大きなハッシュ集約のディスク書き出しを防ぐ目的で利用できるようになりました。
</p>
<li>外部テーブルを継承する通常テーブルに関する問い合わせにおける、誤った実行プラン作成が修正されました。  (Amit Langote) (13)(12)</li>
<p>
SELECT FOR UPDATE や関連するコマンドで、アサート失敗、もしくは、「ERROR:  could not find junk column」が発生していました。
</p>
<li>プラン作成において、FROM 要素が LATERAL であるときの、不変の FROM句内関数結果のプルアップが修正されました。  (Tom Lane) (13)</li>
<p>
問い合わせでクラッシュやアサート失敗を起こす動作が報告されました。
</p>
<li>新しいスタンバイが新しいプライマリに追随する際に稀に発生する障害が修正されました。  (Dilip Kumar, Robert Haas) (13)(12)(11)(10)(9.6)</li>
<p>
いくつかの条件が組み合わさった際にスタンバイが間違った WALタイムラインに従おうとする可能性がありました。
</p>
<li>トランザクションアボートのレコードの WALリプレイがファイル切り捨てを引き起こすときに、最小のリカバリポイントが更新されるようになりました。  (Fujii Masao) (13)(12)(11)(10)(9.6)</li>
<p>
ファイル切り捨ては元に戻せないため、そのレコードよりも前の時点でリカバリを止めることは安全ではありません。トランザクションがコミットされた場合で該当するケースは数年前に修正されていましたが、アボートのケースは修正されていませんでした。
</p>
<li>レプリケーションスロットが無効となった後に「必要とされる最も古いWALセグメント」の境界値を適切に進めるようになりました。  (Kyotaro Horiguchi) (13)</li>
<p>
全てのレプリケーションスロットが無効となった際に境界値を再計算しておらず、最終的にサーバの WAL ストレージが溢れる可能性がありました。
</p>
<li>walreceiver で、エラー発生後にキャッシュからのカタログ検索を試みなくなりました。  (Masahiko Sawada, Bharath Rupireddy) (13)(12)(11)(10)</li>
<p>
これはエラー後において安全な方法ではありません。
</p>
<li>スタンバイサーバにシャットダウンシグナルが送信された場合、まだ起動処理中でWAL受信を待っているであっても、直ちにシャットダウンを実行するようになりました。  (Fujii Masao, Soumyadeep Chakraborty) (13)(12)(11)(10)(9.6)</li>
<li>トランザクションコミットグループへの参加に失敗した際に、共有状態が正しくクリアされるようになりました。  (Amit Kapila) (13)(12)(11)</li>
<p>
タイミングによっては、後のセッションが同じ PGPROCオブジェクトを再利用する場合にアサート失敗が発生する可能性がありました。
</p>
<li>他のプロセスからの同時書き込みに際しても不正な relmapper のデータを読み込みを回避できるように、ロックが追加されました。  (Heikki Linnakangas) (13)(12)(11)(10)(9.6)</li>
<p>
relmapper は OID とファイルノードの対応を保持するデータで、ファイル名は pg_filenode.map です。
</p>
<li>並列B-treeインデックス構築の、ソート段階に関する進捗報告が改善されました。  (Matthias van de Meent) (13)(12)</li>
<p>
パラレルワーカによるソート処理の開始前にも状態報告するようになりました。
</p>
<li>レプリケーションプロトコル違反の検査が改善されました。  (Tom Lane) (13)(12)(11)(10)</li>
<p>
ロジカルレプリケーションワーカは多くの箇所でアサートを用いて、不適切なレプリケーションコマンドの検査を行っていましたが、通常のエラー処理に変更されました。
</p>
<p>
不正な入力に対して、デバッグビルドでアサート失敗で停止することも、実運用ビルドで検査が行われないことも、望ましくありません。
</p>
<li>パーティションテーブルのロジカルレプリケーションで更新時に発生しうるクラッシュが幾つか修正されました。  (Amit Langote, Tom Lane) (13)</li>
<li>ロジカルレプリケーションワーカでパーティションテーブルのAFTERトリガが発動する時に生じる可能性のあったクラッシュが修正されました。  (Tom Lane) (13)</li>
<li>複数ロジカルレプリケーションワーカが同じテーブルを TRUNCATEしようとする際に起こるデッドロックが修正されました。  (Peter Smith, Haiying Tang) (13)(12)(11)</li>
<p>
TRUNCATE実行時にサブスクライバ側で「ERROR: deadlock detected」が発生していました。
</p>
<li>投機的挿入（speculative insertions）のロジカルデコーディングにおける幾つかの誤りが修正されました。  (Dilip Kumar) (13)(12)(11)(10)(9.6)</li>
<p>
投機的挿入は INSERT .. ON CONFLICT .. で使われる処理です。メモリリークや予期せぬエラー、アサート失敗がもたらされる可能性がありました。
</p>
<li>ロジカルレプリケーションのデコーディングによるメモリリークが修正されました。  (Amit Langote) (13)</li>
<li>エラー発生後、データ型キャッシュのハッシュテーブルに無効なレコード型のエントリが残る問題が回避されました。  (Sait Talha Nisanci) (13)(12)(11)</li>
<p>
これは後のクラッシュやメモリリークを引き起こす原因となっていました。
</p>
<li>CREATE TABLE ... AS EXECUTE構文でエラー発生する一部の場合における、プランキャッシュの参照カウントの取りこぼしが修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
結果としてメモリリークが生じる可能性がありました。
</p>
<li>パラレルワーカ間のタプル記述子を共有するコードで競合状態が修正されました。  (Thomas Munro) (13)(12)(11)</li>
<p>
場合によってはクラッシュが発生する可能性がありました。
</p>
<li>checkpointerプロセスによる使われなくなったレプリケーションスロット無効化が、そのスロットを削除や更新しようとする処理と並行して行われたときの競合状態が修正されました。  (Andres Freund, &Aacute;lvaro Herrera) (13)</li>
<li>バックグランドワーカスロット（BackgroundWorkerSlots）を解放する際の潜在的な競合状態が回避されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
Intelハードウェアでは明白にバグが修正されたという結果が観察できないかもしれませんが、メモリオーダリング制御が弱いマシン上では問題が起きる可能性がありました。
</p>
<li>ソートのコードにおける潜在的なクラッシュが修正されました。  (Ronan Dunklau) (13)(12)(11)(10)(9.6)</li>
<p>
あるコードパスで NULLポインタを解放しようとする可能性がありました。本ケースは、コアサーバのソート利用では到達できないように見えますが、拡張から引き起こされる可能性がありました。
</p>
<li>破損データに対して B-tree ポスティングリストを分割するコードが堅牢化されました。  (Peter Geoghegan) (13)</li>
<p>
既存のエントリと同一の TID を持つアイテムを挿入しようとすると、クラッシュするのではなく、エラーを投げるようになりました。 これは決して起こるべきではありませんが、インデックスがそのテーブルと矛盾している時に場合に起こることが報告されています。
</p>
<li>SP-GiST のインデックス挿入における無限ループが防止されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
INCLUDE列がリーフインデックスタプルがページに収まらないほどのスペースを占めている場合、text_ops演算子クラスはタプルを収めるために無駄に無限ループに陥ってしまいました。11以前のバージョンには INCLUDE列がありませんが、演算子クラスのバグに対する良い防御策と思われるので、このループ防止の修正が後方適用されました。
</p>
<li>SP-GiST のインデックス挿入が、クエリキャンセル要求によって終了できることが保証されました。  (Tom Lane, &Aacute;lvaro Herrera) (13)(12)(11)(10)(9.6)</li>
<li>PL/pgSQL で INTO句に STRICT が指定されていないにもかかわらず、あたかも STRICT が指定されているかのように動作する可能性がある、初期化されていない変数のバグが修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<li>libpq の出力関数（PQprint）において、メモリ不足障害が発生しても処理を中断しないようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
これまでは abort(3) でプログラムを終了させていました。
</p>
<li>ecpg で numaric型の INT_MIN（通常は -2147483648）を integer に変換できるようになりました。  (John Naylor) (13)(12)(11)(10)(9.6)</li>
<p>
以前の ecpg の範囲チェックでは INT_MIN ではなく -INT_MAX を範囲内としていたため、-2147483648 が範囲外として拒否されていました。
</p>
<li>psql やその他のクライアントプログラムで不正にエンコードされたデータを扱う際に、文字列の末尾をオーバーランしないようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
文字列の終わり近くに不適切にエンコードされたマルチバイト文字があると、様々な処理ループが文字列の最後の NUL を越えて実行される可能性があり、その結果、後続のメモリに何があるかによって、検出不能な問題からプログラムのクラッシュまで様々な問題が発生します。これは CVE-2006-2313 を想起させますが、これらの特定ケースが注意を喚起させるセキュリティ上の重要性を持つとは思われません。
</p>
<li>有効/無効（あるいは REPLICA/ALWAYS）の状態が親テーブルのトリガと異なるパーティションテーブルのトリガを正しく処理するようにpg_dump が修正されました。  (Justin Pryzby, &Aacute;lvaro Herrera) (13)(12)(11)</li>
<p>
このような場合にダンプで指定されていた状態が失われていました。
</p>
<li>異なるタイムゾーンで作成されたダンプファイルで pg_restore を実行した場合に発生する「invalid creation date in header」という警告が回避されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
新しい glibc バージョンの mktime() の移植性の問題により、異なるタイムゾーンで作成されたダンプファイルに対して pg_restore を実行した時、下記のメッセージが出ていました。
</p>
<pre>
pg_restore: warning: invalid creation date in header
pg_restore: while PROCESSING TOC:
</pre>
<li>pg_upgrade が古いインストールの「oldestXID」の値を引き継ぐようになりました。  (Bertrand Drouvot) (13)(12)(11)(10)(9.6)</li>
<p>
以前、新しいインストールの「oldestXID」は（通常）すぐに周回防止の自動バキュームが強制実行されるような古い値に設定されていました。これはパフォーマンスの観点からは望ましくありません。さらに悪いことに、大きな値の autovacuum_freeze_max_age を使用しているインストールでは、アップグレード直後に不必要な強制シャットダウンが発生する可能性がありました。
</p>
<li>アップグレードすべき拡張を検出して警告を出すように pg_upgrade が拡張されました。  (Bruce Momjian) (13)(12)(11)(10)(9.6)</li>
<p>
これからは、拡張を新PostgreSQLバージョンでデフォルトとされるバージョンにアップグレードするのに必要な ALTER EXTENSION UPDATE コマンドを含む、スクリプトファイルが作成されます。
</p>
<li>pg_receivewal を圧縮WAL格納と非圧縮WAL格納の間で切り替える際の問題が回避されました。  (Michael Paquier) (13)(12)(11)(10)</li>
<li>contrib/postgres_fdw が生成列について有効に動作するよう修正されました。  (Etsuro Fujita) (13)(12)</li>
<p>
外部テーブルの生成列が外部テーブルの生成列をあらわす場合については、適切に動作するようになりました。
</p>
<p>
postgres_fdw は IMPORT でリモートテーブルの生成列を通常の列として取り込み、外部テーブルに INSERT を行う時に「ERROR: cannot insert a non-DEFAULT value into column "..."」というエラーが出ていました。import_generated オプション（デフォルトtrue）が追加され、true なら、IMPORT FOREIGN SCHEMA は生成列を取り込むようになりました。
</p>
<li>contrib/postgres_fdw で、エラーの後にカタログ検索を試みないようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
通常はこの方法で動作しますが、カタログアクセスが機能しないエラーが発生している可能性があるため、あまり安全ではありませんでした。この修正の副作用として、データ変換エラーに関するメッセージで、外部テーブルや外部列の実際の名前ではなく、クエリのテーブルやカラムのエイリアス（使用されている場合）が言及されるようになりました。
</p>
<li>トランザクション隔離のテストの基盤が改善されました。  (Tom Lane, Michael Paquier) (13)(12)(11)(10)(9.6)</li>
<li>キャッシュ上書きの検査のオーバヘッドが軽減されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<li>PL/Python のリグレッションテストが Python 3.10 でも通るように修正されました。  (Honza Horak) (13)(12)(11)(10)(9.6)</li>
<li>PostgreSQLコード内の実装における printf("%s", NULL) がクラッシュする代わりに (null) を出力するようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
これにより、ごく稀な場合でのサーバの堅牢性が向上し、printf の実装が一般的なライブラリと同様となります。
</p>
<li>ポイントインタイムリカバリが ROLLBACK PREPARED レコードで停止した際に出力する誤ったログメッセージが修正されました。  (Simon Riggs) (13)(12)(11)(10)(9.6)</li>
<p>
「recovery stopping before abort of transaction %u, time %s」と出力すべきメッセージが、これまでは、「recovery stopping before commit of transaction %u, time %s」と出力されていました。
</p>
<li>ALTER TABLEで誤ったリレーションタイプに対するエラーメッセージが改善されました。  (Kyotaro Horiguchi) (13)(12)(11)</li>
<pre>
（メッセージ改善例）
db=# CREATE VIEW v69 AS SELECT * FROM t1;
db=# ALTER TABLE v69 ALTER c SET STATISTICS 0;
ERROR:  "v69" is of the wrong type
（修正後のメッセージ）
ERROR:  "v69" is not a table, materialized view, index, partitioned index, or foreign table
</pre>
<li>エラーメッセージ内の「負でない (non-negative)」等がゼロを含むか明確な表現に置き換えられました。  (Bharath Rupireddy) (13)(12)(11)(10)(9.6)</li>
<pre>
db=# CREATE TABLE t70 (c int) PARTITION BY HASH (c);
db=# CREATE TABLE p70 PARTITION OF t70 FOR VALUES WITH (MODULUS 4, REMAINDER 0);

(修正前)
db=# SELECT satisfies_hash_partition('t70'::regclass, 0, 0, NULL);
ERROR:  modulus for hash partition must be a positive integer
db=# SELECT satisfies_hash_partition('t70'::regclass, 1, -1, NULL);
ERROR:  remainder for hash partition must be a non-negative integer

(修正後)
db=# SELECT satisfies_hash_partition('t70'::regclass, 0, 0, NULL);
ERROR:  modulus for hash partition must be an integer value greater than zero
db=# SELECT satisfies_hash_partition('t70'::regclass, 1, -1, NULL);
ERROR:  remainder for hash partition must be an integer value greater than or equal to zero
</pre>
<li>個別の libldap_rライブラリがなくなった OpenLDAP 2.5 で動作するように configure が修正されました。  (Adrian Ho, Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>libldap_rライブラリが存在しない場合は、libldapライブラリは暗黙的にスレッドセーフであると想定されます。
</p>
<li>make ターゲットに新たに world-bin および install-world-bin が追加されました。  (Andrew Dunstan) (13)(12)(11)(10)(9.6)</li>
<p>
これらは、ドキュメントをビルドまたはインストールしないことを除き、world および install-world と同じです。
</p>
<li>TAPテストの makeルール（prove_installcheck）がPGXS の使い方に沿って動作するように修正されました。  (Andrew Dunstan) (13)(12)(11)(10)(9.6)</li>
<li>JITのコードが今後の LLVM API の変更に備えて調整されました。  (Thomas Munro, Andres Freund) (13)(12)(11)</li>
<p>
LLVM 13 では、以前の JIT コンパイラではクラッシュをもたらす、互換性のない API の変更が行われています。
</p>
<li>GSSAPIライブラリから返る文字列が null終端していることを前提としないように修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
GSSAPI の仕様では文字列ポインタと長さを返すことになっています。実際には文字列は通常 null終端されているため、従来コードでもエラーは発生していませんが、AddressSanitizer から問題が報告されました。
</p>
<li>MSVC で GSSAPI を使ったビルドが可能になりました。  (Michael Paquier) (13)(12)(11)(10)(9.6)</li>
<p>
最新の Kerberosビルドとのさまざまな非互換性が修正されました。
</p>
<li>MSVC ビルドで --with-pgport が指定されている場合、pg_config が出力する configure オプションに含めるようになりました。  (Andrew Dunstan) (13)(12)(11)(10)(9.6)</li>
<li>PostgreSQL 10 を ICU 69 以降でビルドできるようになりました。  (Peter Eisentraut) (10)</li>
<li>contrib/pgcrypto で、シンボル名が OpenSSL と競合しないように修正されました。  (Tom Lane) (9.6)</li>
<p>
SHA224ハッシュを使った操作で valgrid がエラーを検知する可能性がありました。これは、アライメント用パディングバイトのメモリ破壊にすぎないため、実際には影響なさそうですが、念のため修正されました。
</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 10.17 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/10-17/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Tue, 25 May 2021 01:55:27 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 10]]></category>
		<category><![CDATA[PostgreSQL 10.16]]></category>
		<category><![CDATA[PostgreSQL 10.17]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=7000</guid>

					<description><![CDATA[このリリースは 10.16 からの修正リリース（2021年5月13日リリース）です。 10.X からのアップデートではダンプ、リストアは不要です。 しかしながら、10.16 よりも前のバージョンから移行する場合には 10 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 10.16 からの修正リリース（2021年5月13日リリース）です。<br />
10.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、10.16 よりも前のバージョンから移行する場合には <a href="/tech-blog/pgsql/10-16">10.16 のリリース情報</a>も確認してください。</p>
<p><span id="more-7000"></span></p>
<h3>PostgreSQL 10.16 から 10.17 への変更点</h3>
<p>13.3、12.7、11.12、10.17、9.6.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>配列の添え字の計算において、整数オーバーフローが防止されました。(CVE-2021-32027)  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
これまでの配列の実装では、配列の下限と長さが整数をオーバーフローさせる場合を問題としていませんでした。その結果、（添え字を整数として書けないため）配列後方のエントリがアクセス不能になり、さらに重要なことには、続く代入操作を混乱させました。このことは、確実なクラッシュや望まないデータ書き換えを伴うメモリ上書きをもたらすおそれがありました。
</p>
<p>
サポート終了バージョンであるため修正はリリースされませんが、9.5以前のバージョンについても同様の問題があると考えられます。
</p>
<li>「INSERT ... ON CONFLICT ... UPDATE」の対象リストで不要列の扱いが修正されました。 (CVE-2021-32028) (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
UPDATE のリストが、適切な結果に加えて不要列（使われない不要な列、ごみ列）を発生させるような複数列の副問い合わせを持つ場合、UPDATE の処理コードは最終的に余分な不要列の値を含むタプルを格納していました。これは短い実行ではおよそ無害ですが、テーブルに新たな列が追加された場合、その値がアクセス可能になってしまい、追加した列とデータ型が合わない場合には不具合になるおそれがありました。
</p>
<p>
加えて、パーティションをまたがる更新に対応したバージョンでは、このようなケースで引き起こされたパーティションをまたがる更新が、逆に対象リストから不要列が削除される問題をもたらし、典型的には即座のクラッシュを引き起こしました。
</p>
<p>
この障害を利用して、一時テーブルを含む、テーブル作成権限を持ったユーザによる、サーバ側の任意メモリを読み取る攻撃も可能でした。
</p>
<pre>
（クラッシュ発生例）
db=# CREATE TABLE t2 (a int PRIMARY KEY, b text) PARTITION BY LIST (a);
db=# CREATE TABLE t2_1 PARTITION OF t2 FOR VALUES IN (1);
db=# CREATE TABLE t2_2 (b TEXT, a INT PRIMARY KEY);
db=# ALTER TABLE t2 ATTACH PARTITION t2_2 FOR VALUES IN (2);
db=# INSERT INTO t2 VALUES(1, 'Boo'), (2, 'Zoo');

db=# WITH aaa AS (SELECT 1 AS a, 'Foo' AS b)
     INSERT INTO t2 VALUES (1, 'Bar') ON CONFLICT (a)
       DO UPDATE SET (b, a) = (SELECT b, a FROM aaa) RETURNING *;
 (a=1、b='Foo' の 1行が返る)

db=# WITH aaa AS (SELECT 1 AS ctea, ' Foo' AS cteb)
     INSERT INTO t2 VALUES (1, 'Bar'), (2, 'Baz') ON CONFLICT (a)
       DO UPDATE SET (b, a) = (SELECT t2.b || cteb, t2.a FROM aaa) RETURNING *;
 (ここでクラッシュ発生)
</pre>
<li>結合を伴いパーティションをまたがる更新に対する UPDATE ...RETURNING 出力の計算が間違っている可能性があり、修正されました。(CVE-2021-32029)  (Amit Langote, Etsuro Fujita) (13)(12)(11)</li>
<p>
パーティションテーブルの UPDATE により、行が物理的に異なる行タイプを持つ別のパーティション（例えば、削除された列のセットが異なるパーティション）に移動された場合、その行に対する RETURNING 結果の計算でエラーや間違った答えが生じる可能性がありました。UPDATE で他のテーブルが対象テーブルに結合されない限り、エラーは発生しません。
</p>
<p>
以下は本障害によりパーティションテーブルの UPDATE で発生するエラーの一例です。
</p>
<pre>
ERROR:  attribute 5 of type record has wrong type
DETAIL:  Table has type record, but query expects integer.
</pre>
<p>
この障害を利用して、一時テーブルを含む、テーブル作成権限を持ったユーザによる、サーバ側の任意メモリを読み取る攻撃が可能でした。
</p>
<li>パーティションテーブルにおける遅延プロパティ制約の調整が修正されました。  (&Aacute;lvaro Herrera) (13)(12)(11)</li>
<p>
遅延プロパティをパーティションテーブルの外部キー制約に適用するとき、ALTER TABLE ... ALTER CONSTRAINT は、リーフパーティション（末端のパーティション）の制約およびトリガの DEFERRABLE および INITIALLY DEFERRED の印付け調整に失敗しました。これにより、これらの制約の予期しない動作が発生しました。
</p>
<p>
バージョンアップ後に ALTER コマンドを実行して、必要なプロパティを設定することで、誤動作しているパーティションテーブルを修正できます。
</p>
<p>
本修正により、リーフパーティションの制約に直接このような ALTER を適用することもできなくなりました。 唯一サポートされているケースは、パーティショニング階層全体が同一の制約プロパティを持つことであるため、このような ALTER はルートパーティション（親テーブル）で適用される必要があります。
</p>
<li>ALTER TABLE ... INHERIT で子テーブルをアタッチする場合、子テーブルで親テーブルの生成列と同じ定義を持つことを確認するようになりました。  (Peter Eisentraut) (13)(12)</li>
<p>
これまでは子テーブルの定義が異なっていても、無視して子テーブルの定義を捨てていました。本修正で親子で生成列の定義が異なる場合にエラーが出るように変更されました。
</p>
<pre>
db=# CREATE TABLE t13_p1 (a int, b int GENERATED ALWAYS AS (a * 2) STORED);
db=# CREATE TABLE t13_c1 (a int, b int GENERATED ALWAYS AS (a * 3) STORED);

（13.2 での動作）
db=# ALTER TABLE t13_c1 INHERIT pp1;
ALTER TABLE

（13.3 での動作）
db=# ALTER TABLE t13_c1 INHERIT pp1;
ERROR:  column "b" in child table has a conflicting generation expression
</pre>
<li>IDENTITY列を NULL可能とすることが禁止されました。  (Vik Fearing) (13)(12)(11)(10)</li>
<p>
GENERATED ALWAYS AS IDENTITY は NOT NULL を意味しますので、明示的な NULL 指定と組み合わせて使用することはできません。
</p>
<li>ALTER ROLE/DATABASE ... SET で role、session_authorization、temp_buffers のパラメータを設定できるようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
以前は、後で使用する際に値が有効であったとしても、過剰な有効性チェックによってこれらのコマンドが拒否されることがありました。 このため、ダンプ/リロードや pg_upgrade の際に、コマンドの順序が乱れてしまうことがありました。
</p>
<li>REINDEX CONCURRENTLY が、インデックスに設定されている統計情報対象を維持するようになりました。  (Michael Paquier) (13)(12)</li>
<p>
これまでは実行前に設定されていた pg_attribute.attstattarget が REINDEX CONCURRENTLY を実行して作成される新しいインデックスで失われていました。
</p>
<li>現在のトランザクションにセーブポイントが存在する場合に、COMMIT AND CHAIN が正しく動作するように修正されました。  (Fujii Masao) (13)(12)</li>
<p>
以下に本修正による動作の違いを示します。
</p>
<pre>
（13.2 での動作）
db=# BEGIN;
db=*# SAVEPOINT foo;
db=*# COMMIT AND CHAIN;
db=#
（↑トランザクションが終了、プロンプトが # に変わっています）

（13.3 での動作）
db=# BEGIN;
db=*# SAVEPOINT foo;
db=*# COMMIT AND CHAIN;
db=*#
（↑正しく動作して再びトランザクション内になります、プロンプトが *# です）
</pre>
<li>WITH RECURSIVE 処理におけるリスト操作のバグが修正されました。  (Michael Paquier, Tom Lane) (13)</li>
<p>
7レベル以上の十分に深い WITH構造の入れ子によりクラッシュや、WITH 入れ子に対する誤ったエラー（下記）が発生していました。
</p>
<pre>
ERROR:  stack depth limit exceeded
</pre>
<li>COLLATE式の結果を照合不能な型に強制変換する際のバグが修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
本障害により、COLLATE が照合不能な値に適用されているように見える解析ツリーが作成されていました。COLLATE は実行時には影響しないため、通常の使用上の影響はありませんが、ダンプ/リロード時に拒否されるビューを作成することがありえました。
</p>
<pre>
（誤動作例： \d 出力のビュー定義の COLLATE句 が余計で、この SELECT はエラーになる）
db=# CREATE VIEW v9 AS
       SELECT c1+1 AS c1p FROM (SELECT ('4' COLLATE "C")::INT AS c1) ss;
db=# \d+ v9
                             View "public.v9"
 Column |  Type   | Collation | Nullable | Default | Storage | Description
--------+---------+-----------+----------+---------+---------+-------------
 c1p    | integer |           |          |         | plain   |
View definition:
 SELECT ss.c1 + 1 AS c1p
   FROM ( SELECT 4 COLLATE "C" AS c1) ss;
</pre>
<li>AFTERトリガのタプルを保存する際に生じていたメモリを解放した後に再使用する、use-after-free バグが修正されました。  (Amit Langote) (13)(12)</li>
<p>
これにより状況によってはクラッシュをおこす可能性がありました。
</p>
<li>fastpathプロトコル（関数呼び出しサブプロトコル）のメッセージによるウィンドウ関数およびプロシージャの呼び出しが禁止されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
ここでは普通の関数のみがサポートされます。集約関数の呼び出しはすでにエラーとなっていましたが、ウィンドウ関数の呼び出しはクラッシュし、プロシージャの呼び出しはそのプロシージャがトランザクション制御を行わない場合にのみ機能していました。
</p>
<li>イベントトリガをサポートするために pg_identify_object_as_address() が拡張されました。  (Joel Jacobson) (13)(12)(11)(10)(9.6)</li>
<p>以前は、pg_event_trigger に対する本関数の実行で、予期せぬエラー「ERROR:  requested object address for unsupported object class 32: text result "ddl_postgrest"」が発生していました。
</p>
<li>to_char() による負の間隔を持つローマ数字の月形式コードの処理が修正されました。  (Julien Rouhaud) (13)(12)(11)(10)(9.6)</li>
<p>
以前そのような時は通常クラッシュを引き起こしてました。
</p>
<pre>
（修正前 13.2 ではクラッシュ）
db1=# SELECT * from TO_CHAR(interval '-1Mon', 'rm');
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

（修正後 13.3 の動作例）
db=# SELECT * from TO_CHAR(interval '-1Mon', 'rm');
 to_char
---------
 xii
(1 row)
</pre>
<li>pg_import_system_collations() の引数が有効なスキーマの OID かを確認して、無効ならエラーを出すようになりました。  (Tom Lane) (13)(12)(11)(10)</li>
<p>
これまで不正な値に対してアサート失敗が生じていました。アサート無効のビルドでは、おそらく無害ですが pg_collation に無効な collnamespace列の値を持ったエントリができる可能性がありました。
</p>
<li>基本RE(BRE)モードの正規表現で \{m,n\} 数量詞を解析する際に初期化されていない値の使用が修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
この誤りにより、数量詞が欲張りでない動作をする可能性がありました。すなわち、完全な正規表現（ARE) における {m,n}? 数量詞の動作と同様に振る舞いました。
</p>
<li>ソートキーに集約関数やウィンドウ関数が含まれている状況で、プランナのエラー「ERROR:  could not find pathkey item to sort」が出る問題が修正されました。  (James Coleman, Tom Lane) (13)</li>
<li>拡張統計を用いてグループ数を推定する際、システム列を無視しないように修正されました。  (Tomas Vondra) (13)(12)(11)(10)</li>
<p>
これまでは (a, b) の拡張統計が存在するテーブルに対する「SELECT ... GROUP BY a, b, ctid」といったシステム列を含めた問い合わせの推定値がおかしくなっていました。
</p>
<li>長い固定プレフィックスを持つ正規表現に対する選択度(selectivity)の評価を行う際に発生するゼロ除算問題が回避されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
通常、選択度は NaN と評価され、後にアサート失敗や奇妙なプランナ動作を引き起こす可能性がありました。
</p>
<p>
下記の正規表現を使用してアサート失敗が発生するケースが報告されました。
</p>
<pre>
SELECT * FROM test WHERE t ~* ('^' || repeat('-', 500));
</pre>
<li>BRINインデックスを使用するとき、ビットマップインデックススキャンを行う際にテーブル範囲外にアクセスしようとするエラーが発生する可能性があり、修正されました。  (Tomas Vondra) (13)(12)(11)(10)(9.6)</li>
<p>
BRINインデントのページ範囲サイズが 2 の累乗でなければ、ビットマップスキャンがテーブル実際の終りより先のページを読み込もうと試み、稀に「ERROR:  could not open file」が出ることがありました。
</p>
<li>GINインデックスの検索でマッチするタプルが複数存在する場合、間違った値を返す可能性があり、修正されました。  (Tom Lane) (13)</li>
<p>
マッチするインデックス数が過大になると（閾値は work_mem 設定値で決まります）、保持しているビットマップは損失を伴うもの（lossy）になります。このとき、再チェック（recheck）は不要と誤判断する可能性があり、誤った問い合わせ結果を返すことがありました。
</p>
<li>Windows における WALセグメント再利用時の同時実行問題が修正されました。  (Michael Paquier) (13)</li>
<p>
以前（13.0 リリース前）の修正によって「LOG: could not rename file ...: Permission denied」というログメッセージが断続的に出力されていて、その修正が元に戻されました。深刻な問題ではありませんでしたが大量のログ出力が迷惑でした。
</p>
<li>コミットされていない二相トランザクションを WAL からリカバリする時に発生する、不適切なタイムライン変更が回避されました。  (Soumyadeep Chakraborty, Jimmy Yih, Kevin Yeap) (13)(12)(11)(10)</li>
<p>
この不具合により、後続の WALレコードは間違ったタイムラインID で記録され、整合性が取れなくなる問題や、サーバが再起動できなくなる問題が起きる可能性がありました。
</p>
<li>スタンバイサーバが起動中にシャットダウンされた場合に、確実にロックが全て解放されるようになりました。  (Fujii Masao) (13)(12)(11)(10)(9.6)</li>
<p>
スタンバイサーバがリカバリの途中で切断されると、保持しているロックが一部残る可能性があり、デバッグが有効なビルドではアサート失敗が発生していました。本番ビルドで重大な問題が発生するかは不明です。
</p>
<li>論理レプリケーションワーカが「ALTER SUBSCRIPTION ... REFRESH PUBLICATION」を実行するときにクラッシュしてしまう問題が修正されました。  (Peter Smith) (13)(12)(11)(10)</li>
<p>
通常のコマンド実行では問題がありませんが、レプリカのトリガから実行するときにクラッシュが発生しました。
</p>
<li>最近のバージョンの FreeBSD において、wal_sync_method 設定がデフォルトで fdatasync になるように修正されました。  (Thomas Munro) (13)(12)(11)(10)(9.6)</li>
<p>
FreeBSD 13 は open_datasyncをサポートしているため、通常、それがデフォルトで選択されました。しかしながら PostgreSQLにとってそれがより優れた選択とは限られませんので、既存のデフォルト設定のままにするようになりました。
</p>
<li>vacuum_cleanup_index_scale_factor設定とストレージオプションが無効にされました。  (Peter Geoghegan) (13)</li>
<p>
古くなった統計情報を追跡するという考えはautovacuum_vacuum_insert_threshold設定とは相性が悪く、結果として必要のないフルインデックススキャンが行われ、autovacuum のパフォーマンス劣化につながりました。autovacuum_vacuum_insert_threshold の仕組みがより優れていると判断されて、古い統計情報のロジックが削除されました。
</p>
<p>
vacuum_cleanup_index_scale_factor設定はバージョン14 から完全に削除されます。既存の設定ファイルにも影響を及ぼすという懸念から、バージョン13 ではまだパラメータが残されていますが、機能はしなくなりました。
</p>
<li>ALTER CONSTRAINT 内で、ALTER 処理後に実行されるフックに正しくトリガの OID を渡すように、修正されました。  (&Aacute;lvaro Herrera) (13)(12)</li>
<p>
ALTER CONSTRAINT の中でトリガを更新する際、ALTER 処理後のフックはトリガを更新するものと知らされますが、ここでトリガの OID ではなくトリガのための制約の OID が渡されていました。ALTER 後に誤った制約の動作が生じました。
</p>
<pre>
（修正前バージョン 13.2 での障害動作例）
db=# CREATE TABLE pt27m (k1 int, k2 int, PRIMARY KEY (k1, k2)) PARTITION BY LIST (k1);
db=# CREATE TABLE p27m1 PARTITION OF pt27m FOR VALUES IN (1);
db=# CREATE TABLE pt27t (k1 int, k2 int, v int) PARTITION BY LIST (k1);
db=# CREATE TABLE p27t1 PARTITION OF pt27t FOR VALUES IN (1);

db=# BEGIN;
db=*# ALTER TABLE pt27t ADD CONSTRAINT fkey1 FOREIGN KEY (k1, k2) REFERENCES pt27m;
db=*# ALTER TABLE pt27t ALTER CONSTRAINT fkey1 DEFERRABLE INITIALLY DEFERRED;

db=*# INSERT INTO pt27m VALUES (1, 2);
db=*# INSERT INTO pt27t VALUES (1, 2, 100);
db=*# DELETE FROM pt27m;
ERROR:  update or delete on table "p27m1" violates foreign key constraint "pt27t_k1_k2_fkey" on table "pt27t"
DETAIL:  Key (k1, k2)=(1, 2) is still referenced from table "pt27t".

（最後の DELETE による制約違反はコミット時までエラーにならないのが本来の期待される動作です）
</pre>
<li>DSM（動的共有メモリ）のセグメントをデタッチする時に、割り込まれても片付けが完了できることが保証されました。  (Thomas Munro) (13)(12)(11)(10)(9.6)</li>
<p>
パラレルクエリで作成されたテンポラリファイルが即時に削除されない問題が発生する可能性がありました。
</p>
<li>幾つかの軽微なメモリリークが修正されました。  (Tom Lane, Andres Freund) (13)(12)(11)(10)(9.6)</li>
<li>共有メモリにある walreceiver の統計情報中の変数が初期化されない問題が、修正されました。  (Fujii Masao) (13)</li>
<p>
この誤りは殆どのプラットフォームで無害ですが、アトミック変数やスピンロックがサポートされないプラットフォームでは下記のエラーが発生する可能性がありました。
</p>
<pre>
ERROR:  invalid spinlock number: 0
</pre>
<li>dtrace が無効になっているとしても、コンパイルされていたなら軽量ロック（LWLock）を追跡するプローブが実行されていたものが修正され、オーバーヘッドが軽減されました。  (Peter Eisentraut) (13)</li>
<li>PL/pgSQL の DOブロックで複合型変数とトランザクション制御を両方使用する際に、エラーが発生していたものが、修正されました。  (Tom Lane) (13)(12)(11)</li>
<p>
修正前は以下のようなエラーが発生していました。
</p>
<pre>
ERROR:  tupdesc reference ... is not owned by resource owner TopTransaction
</pre>
<li>メッセージ長が破損している ParameterDescriptionメッセージを受信したときに発生していた libpq の無限ループが防止されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<li>Windows で、initdb 実行後、最後に出力されるサーバの起動方法を示すコマンド例における pg_ctl のパスが、バックスラッシュを用いて表示するように修正されました。  (Nitin Jadhav) (13)(12)(11)(10)</li>
<pre>
（initdb 出力メッセージの例）

成功しました。以下のようにしてデータベースサーバを起動できます。

　^"C^:^/Install^ Dir^/bin^/pg^_ctl^" -D ^"C^:^\database^\data^" -l &lt;ログファイル&gt; start

（↓上記が以下のように出力されるようになります）

　^"C^:^\Install^ Dir^\bin^\pg^_ctl^" -D ^"C^:^\database^\data^" -l &lt;ログファイル&gt; start
</pre>
<li>psql で \connect service=something が以前の振る舞いに戻されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
以前のバグ修正により、PGPORT などの環境変数が接続サービスファイルのエントリを上書きしていました。サービスファイルでの指定が優先される、以前の振る舞いに戻されました。
</p>
<li>COMMIT AND CHAIN コマンドが正しく処理されるように、psql の ON_ERROR_ROLLBACK機能が修正されました。  (Arthur Nascimento) (13)(12)</li>
<p>
psql が COMMIT AND CHAIN によって既に解放済みの自動発行セーブポイントを解放しようとして、「ERROR:  savepoint "pg_psql_temporary_savepoint" does not exist」というエラーになっていました。
</p>
<li>psql コマンドで「could not print result table: ...」メッセージが繰り返し出力される動作が回避されました。  (&Aacute;lvaro Herrera) (13)</li>
<li>psql の \e および関連コマンドによるファイル変更を検出する際の競合状態が修正されました。  (Laurenz Albe) (13)(12)(11)(10)(9.6)</li>
<p>
高速な入力を行うと、一時編集ファイルの変更をファイルタイムスタンプから検知できないことがありえました。直近のファイル変更内容が反映されない動作をすることが報告されました。
</p>
<li>pg_dump でパーティションテーブルの生成列のダンプが修正されました。  (Peter Eisentraut) (13)(12)</li>
<p>
前マイナーリリースで導入された修正はパーティションテーブルには適用すべきではなく、従来からの継承テーブルにのみ適用すべきでした。
</p>
<li>pg_restore でのファイルのバージョンチェックの誤りが修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
シークできないカスタム形式のダンプファイルを読み取る場合、pg_restore はダンプファイルのバージョンを確認していませんでした。サポートされているものより新しいダンプファイルの形式が提供された場合、リストアに失敗することになります。
</p>
<p>
pg_restore が「pg_restore: [archiver] unsupported version (...) in file header」のエラーを出す代わりにクラッシュする動作が報告されました。
</p>
<li>pg_upgrade に、アップデートできないデータ型を含むユーザーテーブルの検査が追加されました。  (Tom Lane) (13)(12)(11)(10)(9.6)</li>
<p>
アップグレード不可能なデータ型がコンテナ型（配列や範囲など）に埋め込まれている場合の検出が改善されました。
</p>
<p>
また、ユーザーテーブルにシステム定義の複合型の列（システムテーブルを複合型として使っている場合など）が含まれている場合には、それらの型の OID はバージョン間で安定していないため、アップグレードを許可しないようになりました。
</p>
<li>pg_checksums の進行報告が最後に 100％に到達しない不具合が修正されました。  (Shinya Kato) (13)(12)</li>
<li>pg_waldump が、レコード毎の統計を生成するとき XACTレコードを正しくカウントするように、修正されました。  (Kyotaro Horiguchi) (13)(12)(11)(10)(9.6)</li>
<li>contrib/amcheck で、タプルフラグ HEAP_XMAX_LOCK_ONLY と HEAP_KEYS_UPDATED の両方が設定されていることに対して、エラーを出さないように修正されました。  (Julien Rouhaud) (13)(12)(11)(10)(9.6)</li>
<p>
これは SELECT FOR UPDATE 実行後においては正常な状態でした。
</p>
<li>VPATH構築が Oracle Developer Studio の最新版のコンパイラをサポートするように調整されました。  (Noah Misch) (13)(12)(11)(10)(9.6)</li>
<li>Solaris 上で稼働する Python 3 用の PL/Python のテストが修正されました。  (Noah Misch) (13)(12)(11)(10)(9.6)</li>
<li>サーバ側SSLパラメータを初期化するときのメモリリークが修正されました。  (Michael Paquier) (12)(11)(10)</li>
<p>
通常、深刻な影響はありませんが、postmaster に SIGHUPシグナルが繰り返し送信されると、時間の経過と共にメモリリークが増大する可能性があります。
</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 10.16 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/10-16/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Tue, 02 Mar 2021 08:37:38 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 10]]></category>
		<category><![CDATA[PostgreSQL 10.15]]></category>
		<category><![CDATA[PostgreSQL 10.16]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=6757</guid>

					<description><![CDATA[このリリースは 10.15 からの修正リリース（2021年2月11日リリース）です。 10.X からのアップデートではダンプ、リストアは不要です。 しかしながら、１番、３番、４番の項目にはバージョンアップ後に実施すべき手 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 10.15 からの修正リリース（2021年2月11日リリース）です。<br />
10.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、１番、３番、４番の項目にはバージョンアップ後に実施すべき手順があります。</p>
<p><span id="more-6757"></span>また、10.11より前のバージョンからアップデートする場合には<a href="/tech-blog/pgsql/10-11/">10.11のリリース情報</a>も参照してください。</p>
<h3>PostgreSQL 10.15 から 10.16 への変更点</h3>
<p>13.2、12.6、11.11、10.16、9.6.21、9.5.25 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>一部の結合の問い合わせで列単位の SELECT権限の検査に失敗していたものが、修正されました。 (Tom Lane) (13)</li>
<p>
結合を伴う一部のケースで、問い合わせで読み込まれた全ての列をパーサが権限検査に使う使用列ビットマップに記録することに失敗していました。エグゼキュータは問い合わせ実行のためにいくつかの種類の SELECT権限を依然として要求するものの、これはテーブルの一列にのみ SELECT権限を持ったユーザが、工夫をこらした問い合わせを通して全ての列を読むことができることを意味します。
</p>
<p>
本問題に該当する問い合わせの格納されたビューは、不完全な使用列ビットマップを持ちます。そのため、アップデート後でもビューに適切なパーミッションが強制されません。セキュリティが列単位のアクセス制御に依存したインストレーションでは、全てのユーザ定義ビューに「CREATE OR REPLACE ...」を実行し直して、再パースさせることが推奨されます。(CVE-2021-20229)
</p>
<li>制約違反エラーメッセージでの情報漏洩が修正されました。 (Heikki Linnakangas) (13)(12)(11)</li>
<p>
UPDATEコマンドで異なるパーティションに行を移動しようとして、宛先パーティションでの何らか制約違反になって、かつ、そのパーティションの列が親テーブルと異なる物理位置である場合、エラーメッセージにユーザが SELECT権限を持たない列の内容が露出する可能性がありました。(CVE-2021-3393)
</p>
<li>GiSTインデックスに挿入する際の同時ページ分割の誤検知が修正されました。 (Heikki Linnakangas) (13)(12)</li>
<p>
同時挿入により、誤ったページにエントリが配置されるインデックス破損が起きる可能性がありました。バージョンアップ後、同時挿入をしたかもしれない全ての GiSTインデックスを再作成をすることが推奨されます。
</p>
<li>CREATE INDEX CONCURRENTLY が同時実行の準備されたトランザクションを待機するように修正されました。 (Andrey Borodin) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
CREATE INDEX CONCURRENTLY が全ての同時実行トランザクションで挿入した行が可視になるようにそれらが完了するのを待機する箇所で、同じく全ての準備されたトランザクションが完了するのも待機しなければなりませんでした。これを行っていなかったことで、準備されたトランザクションにより挿入された行が新たなインデックスから無視されて、インデックスを使った問い合わせでそのような行が取りこぼされて、誤った問い合わせ結果が生じる可能性がありました。
</p>
<p>
プリペアドトランザクションを使っているインストレーション（max_prepared_transactions が 1以上）では、本障害が起きている場合に備えて、全ての同時作成したインデックスを REINDEX することが推奨されます。
</p>
<li>ハッシュされたグルーピングセットとソートされたグルーピングセットの両方を持った集約プランノードの再スキャンを試みたときのクラッシュが回避されました。 (Jeff Davis) (13)</li>
<pre>
（クラッシュが生じるプラン形状の例）
db=# CREATE TABLE t5 (i int, j int);
db=# INSERT INTO t5 SELECT g/10, g FROM generate_series(1,40) g;
db=# explain (costs off) SELECT * FROM (VALUES (1),(2)) v(a),
       LATERAL (SELECT v.a, i, j, count(*) FROM t5 GROUP BY cube(i,j)) s
       ORDER BY v.a, i, j;
                 QUERY PLAN
--------------------------------------------
 Sort
   Sort Key: "*VALUES*".column1, t5.i, t5.j
   -&gt;  Nested Loop
         -&gt;  Values Scan on "*VALUES*"
         -&gt;  MixedAggregate
               Hash Key: t5.i, t5.j
               Hash Key: t5.i
               Hash Key: t5.j
               Group Key: ()
               -&gt;  Seq Scan on t5
(10 行)
</pre>
<li>ハッシュ集約ノードが一部のテーブルについてディスク書き出しを行うときに、誤った問い合わせ結果の可能性があり、修正されました。 (Tom Lane) (13)</li>
<p>
タプルが読み戻されたときに、集約のグルーピング値が NULL に置き換わる可能性があって、誤った問い合わせ結果につながりました。
</p>
<li>インクリメンタルソートにおける境界条件的なケースの障害が修正されました。 (Neil Chen) (13)</li>
<p>
ソートバッチの最後のタプルが偶然に既にソート済みの次グループの最初のタプルになった場合、これまでのコードは誤動作しました。これは「ERROR: retrieved too many tuples in a bounded sort」エラーか、エラー無しに誤った問い合わせ結果をもたらします。
</p>
<li>トランザクションのロールバックを行う CALL文または DO文が実行されたときのクラッシュが回避されました。 (Thomas Munro, Tom Lane) (13)(12)(11)</li>
<p>
PostgreSQL 13.x では、本ケースで確実に NULLポインタ参照が起きます。PostgreSQL 12.x、11.x では目に見える症状は現れないようですが、問題が決して起きないとは言えません。
</p>
<p>
以下を拡張問い合わせとして実行して、クラッシュする動作が報告されました。
</p>
<pre> DO $$ BEGIN ROLLBACK; END $$;
</pre>
<li>パーティションテーブルにおける BEFORE UPDATEトリガでの不要なエラーを回避しました。 (Alvaro Herrera) (13)</li>
<p>
行を変更した BEFORE UPDATE FOR EACH ROW トリガーは、何であれ、UPDATE が行を他パーティションに移動するのを妨げました。しかし、この制限をもうける必要がもはやありませんでした。
</p>
<p>
本状況でこれからは以下のエラーが発生しなくなります。
</p>
<pre>ERROR: moving row to another partition during a BEFORE trigger is not supported
</pre>
<li>問い合わせにおけるパーティション除外のロジックが、非対称なハッシュパーティションセットを扱えるように修正されました。 (Tom Lane) (13)(12)(11)</li>
<p>
ハッシュパーティションテーブルがサイズの異なるパーティション（即ち一様でない法の値）を持っている場合、あるいは、一部の残余の値に対してパーティションが欠けている場合、プランナの除外ロジックが除外可能なパーティションについて誤判断して、在るべき行が欠けた誤った問い合わせ結果が生じる可能性がありました。
</p>
<li>WHERE CURRENT OF が MergeAppendノードを含む実行プランに対するカーソルに使用されたときの誤った結果を回避するようになりました。 (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
このケースは本来サポートされません（一般に ORDER BY を使ったカーソルが必ず更新可能となることは保証されません）。しかしながら、これまでの実装では拒絶しておらず、エラー無しに誤った問い合わせ結果（誤った更新）が生じる可能性がありました。
</p>
<li>CustomScanノードを含む実行プランに対するカーソルにWHERE CURRENT OF が使われたときのクラッシュが修正されました。 (David Geier) (13)(12)(11)(10)(9.6)(9.5)</li>
<li>プランナで外部結合のために遅延評価すべきプレースホルダに対する誤った処理が修正されました。 (Tom Lane) (13)(12)</li>
<p>
これは特に外部結合の出力に対する LATERAL参照を含む副問い合わせで発生します。この誤りにより異常な形状のプランが生じるおそれがありました。報告されているケースでは「ERROR: failed to assign all NestLoopParams to plan nodes：...」が生じましたが、それ以外の症状になる可能性もあります。
</p>
<p>
以下の形状の SQL で上記エラーが生じる動作が報告されました。
</p>
<pre>SELECT t13u.znum, g.v
  FROM t13u
  LEFT JOIN t13b on t13b.txt ~ 'xxx'
  LEFT JOIN LATERAL (SELECT regexp_replace(t13b.txt, 'xxx', '')::int v)
    AS g ON true
  LEFT JOIN t13r WHERE t13r.bnum = g.v;
</pre>
<li>プランナで不要な RESULT RTE を削除する際のプレースホルダ処理が修正されました。 (Tom Lane) (13)(12)</li>
<p>
RESULT RTE とは問い合わせの結果出力で使うリレーションを意味します。
</p>
<p>
この誤りにより、「ERROR: no relation entry for relid N」（Nは数値）というエラーが生じる可能性がありました。
</p>
<pre>（本障害を発生させる SELECT文の例）
 SELECT z, a, b FROM (SELECT 0 AS z) AS t1
   LEFT JOIN (SELECT true AS a) AS t2 ON true,
   LATERAL (SELECT true AS b UNION ALL SELECT a AS b) AS t3 WHERE b;
</pre>
<li>プランナで、ある結合レベルで計算されて、その同じレベルでしか使われないプレースホルダの処理が修正されました。 (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
この誤りにより「ERROR: failed to build any N-way joins」（Nは数値）というプランナのエラーが生じる可能性がありました。
</p>
<p>
結合に LATERAL参照を使っている場合に発生が報告されました。
</p>
<li>Gather Merge操作をプラン作成するときにソートされていない副パスを考慮するように修正されました。 (James Coleman) (13)</li>
<p>
明示的に Sortノードを加えることでこのようなパスの使用は可能で、一部のケースではより優れたプランを生み出します。
</p>
<li>ソートを並列化しようとするときに、PARALLEL RESTRICTED な関数や集合を返す関数を伴う ORDER BY式については考慮外とするようにプランナが修正されました。 (James Coleman) (13)</li>
<p>
この場合、安全にワーカプロセスにプッシュすることはできませんが、インクリメンタルソート機能で誤ってこれらをプラン候補に含めてしまっていました。本障害でバックエンドプロセスのクラッシュが報告されています。
</p>
<li>インデックスのAM（アクセスメソッド）が mark/restore をサポートするかどうかについて、より注意深く扱われるようになりました。 (Andrew Gierth) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
これは稀なケースでサポート関数が欠けていることによるエラーを防止します。
</p>
<p>
GiSTインデックスを使った Merge Join でエラー「ERROR: function ammarkpos is not defined for ...」が生じる動作が報告されました。
</p>
<li>並列問い合わせで必要とする共有メモリ量の過大見積が修正されました。 (Takayuki Tsunakawa) (13)(12)(11)</li>
<li>ALTER DEFAULT PRIVILEGES が重複する引数を安全に扱うように修正されました。 (Michael Paquier) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
同コマンド内の重複したロール名やスキーマ名は、「ERROR: tuple already updated by self」エラーやユニーク制約違反をもたらす可能性がありました。
</p>
<li>pg_authid が変更されたときに、ACL関連のキャッシュがフラッシュされるようになりました。 (Noah Misch) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
この変更により、ALTER ROLE ... [NO] INHERITの結果が迅速に反映されて権限判定が行われるようになります。
</p>
<li>現在のトランザクションで書き換えられたテーブルについて、スナップショットが古すぎるかの判定に失敗する不具合が修正されました。 (Kyotaro Horiguchi, Noah Misch) (13)</li>
<p>
この不具合は、wal_level が minimal に設定された状態で、テーブルがALTER TABLE SET TABLESPACE で書き換えされていた場合でのみ発生します。 問い合わせで「ERROR: snapshot too old」が報告されない可能性がありました。
</p>
<li>現在のトランザクション内でテーブルを作成または書き換えしている場合にの CREATE PUBLICATION の偽性のエラーが修正されました。 (Kyotaro Horiguchi) (13)</li>
<p>
「ERROR: cannot access temporary or unlogged relations during recovery」や「ERROR: table ... cannot be replicated」が出る可能性がありました。この不具合は、wal_level が minimal に設定されている場合のみ発生します。 したがって、以下の警告が出るべきでした。「WARNING: wal_level is insufficient to publish logical changes」
</p>
<li>あいまいな CREATE TABLE の LIKE句の誤処理が防止されました。 (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
CREATE TABLE ... LIKE ではテーブルを新しく作成した後、インデックスなどの取り込みを処理するために、LIKE句の再検査をします。この再検査で同じ名前の別のテーブルが見つかり、予期しない動作が発生する可能性がありました。一例として、新しく作成されるテーブルが、LIKE の対象と同じ名前の一時テーブルである場合が挙げられます。
</p>
<pre>（以下を実行すると主キーインデックスの無い s24.t24 が作られてしまいます）
db=# CREATE TABLE public.t24 (id int PRIMARY KEY);
db=# BEGIN;
db=# CREATE SCHEMA s24;
db=# SET LOCAL search_path TO s24, public;
db=# CREATE TABLE t24 (LIKE t24 INCLUDING ALL);
db=# COMMIT;
</pre>
<li>外部キー制約を作成する前にインデックスが複製されるように、CREATE TABLE ... LIKE の処理順序を並べ替えるようになりました。 (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
これにより、CREATE TABLE で宣言された自己参照外部キー制約が、LIKE句によるインデックスに依存するケースが修正されました。
</p>
<p>
以下のような SQL が以前は動作していたものが、直近のマイナーバージョンからエラーになることが報告されました。
</p>
<pre>db=# CREATE TABLE t25_base (id int PRIMARY KEY);
db=# CREATE TABLE t25_inherited (
       LIKE id_base INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES,
       self_ref_if INT,
       FOREIGN KEY (self_ref_if) REFERENCES t25_inherited (id)
   ) INHERITS (t25_base);
ERROR:  there is no unique constraint matching given keys for referenced table "t25_inherited"
</pre>
<li>システムカタログに対する拡張統計オブジェクトの作成が禁止されました。 (Tomas Vondra) (13)(12)(11)(10)</li>
<p>
ただし、allow_system_table_mods = on であれば引き続き作成可能です。
</p>
<li>継承された子テーブルをビューに変換することが禁止されました。 (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
元々、ビューをテーブルの継承ツリーに加える操作は禁止されています。このような変換を含む継承ツリーに対する問い合わせでエラーやクラッシュが生じる可能性がありました。
</p>
<pre>db=# CREATE TABLE t27a (id int);
db=# CREATE TABLE t27b (id int);
db=# CREATE TABLE t27c () INHERITS (t27a);

(通常のテーブルは CREATE RULE でビューに変換できます)
db=# CREATE RULE "_RETURN" AS ON SELECT TO t27b DO INSTEAD SELECT id FROM t27a;

(継承の子テーブルはビューに変換できなくなります)
db=# CREATE RULE "_RETURN" AS ON SELECT TO t27c DO INSTEAD SELECT id FROM t27a;
ERROR:  could not convert table "t27c" to a view because it has child tables
</pre>
<li>削除されたリレーションに割り当てられたディスクスペースが、コミット時にすぐ解放されることが保証されました。 (Thomas Munro) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
これまでは、そのテーブルやインデックスが複数セグメントにわたっている場合に、先頭セグメントだけは即座にサイズゼロになりますが、残りのセグメントは単純にファイル削除を行っていたため、他のバックエンドがファイルオープンしている間はディスクスペースが解放されませんでした。
</p>
<li>パーティションテーブルによって参照されているけれども、実際のデータは格納されないテーブルスペースを削除できないようになりました。 (Alvaro Herrera) (13)(12)(11)</li>
<p>
以前は削除できましたが、パーティション化されたリレーションに対して、その後に行われる操作が失敗しました。 クラッシュが生じるケースが報告されています。
</p>
<li>CLUSTERコマンドの進捗状況報告が正しく行われるようになりました。 (Matthias van de Meent) (13)(12)</li>
<p>
pg_stat_progress_cluster の heap_blks_scanned列の値が誤っていました。
</p>
<li>COPY FROM でバックスラッシュでエスケープされたマルチバイト文字を正しく処理できるようになりました。 (Heikki Linnakangas) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
これまではバックスラッシュとそれに続くマルチバイト文字は正しく処理されませんでした。一部のクライアント文字エンコーディングでは、この影響によりマルチバイト文字の一部がフィールドセパレータまたはコピーデータの終わりを表すマーカーとして、誤って解釈される可能性がありました。
</p>
<li>ANALYZEオプションのない EXPLAIN で、エグゼキュータのハッシュテーブルが事前に割り当てられないようになりました。 (Alexey Bashtanov) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
実際の問い合わせ実行はしないので不要な動作でした。
</p>
<li>最近の修正により発生するようになった、LISTEN/NOTIFY のキュー処理における競合状態が修正されました。 (Tom Lane) (13)</li>
<p>
新しく LISTEN しているバックエンドが、切り捨てられている途中の SLRU ページを読み取ろうとして、エラーが発生する可能性がありました。<br />
</o></p>
<p>
「WARNING: NOTIFY queue is NN% full」（NNは数値）や、「ERROR: too many notifications in the NOTIFY queue」が生じます。
</p>
<li>jsonb 連結演算子が JSONデータ型のすべての組み合わせを処理できるようになりました。 (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
2つの JSONオブジェクト、または 2つの JSON配列を連結できるようになりました。配列以外のオブジェクトを 1要素の JSON配列でラップした後、JSON配列の連結を実行することにより、すべての組み合わせを処理できるようになりました。
</p>
<p>
修正以前は、オブジェクト結合のいくつかの組み合わせは、この方式で結合されていましたが、その他の組み合わせはエラーになりました。
</p>
<li>BREモードの正規表現で「*」数量詞を解析する際の、未初期化値の使用による不具合が修正されました。 (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
この不具合により、「*」数量詞が完全な正規表現(ARE)で実行された最短マッチの動作、すなわち「*?」のように動作する可能性があります。
</p>
<li>指数がちょうど INT_MIN（-2147483648）である場合について、numeric を返す power() の動作が修正されました。 (Dean Rasheed) (13)(12)(11)(10)(9.6)</li>
<p>
「^」演算子も同様に該当します。
</p>
<pre>(報告された誤動作例、2行目の pow は正しくは 0.7678656556403084 )
db=# SELECT n, 1.000000000123^n AS pow FROM (VALUES (-2147483647), (-2147483648), (-2147483649)) AS v(n);
      n      |        pow
-------------+--------------------
 -2147483647 | 0.7678656557347558
 -2147483648 | 1.0000000000000000
 -2147483649 | 0.7678656555458609
(3 rows)
</pre>
<li>substring() 関数の整数オーバーフローの不具合が修正されました。 (Tom Lane, Pavel Stehule) (13)(12)(11)</li>
<p>
引数に指定された開始インデックスと長さを加算して、整数のオーバーフローが発生した場合、誤動作を引き起こしていました。「ERROR: negative substring length not allowed」が生じるか、あるいは、エラーは出ずに単に文字列全体が返されました（大部分のケースはこちらです）。
</p>
<li>SLRUログ周回点の誤検出によるデータ損失の可能性が防止されました。 (Noah Misch) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
通常、周回点にはページの半ばで到達し、これをページの境界に丸める必要がありましたが、正しく行われていませんでした。データベースクラスタが SLRUオーバーフローまでの 1ページ以内に到達しない限り、この問題は発生せず、適切に機能しているシステムで起こる可能性は低いです。
</p>
<p>
この問題が発生した場合、後の「apparent wraparound」を含むログメッセージや「ERROR: could not access status of transaction」のエラーで顕在化します。「LOG: could not truncate directory "pg_xact": apparent wraparound」が出るケースが報告されました。
</p>
<li>タイムラインスイッチを正しく処理するように、WAL読み取りロジックが修正されました。 (Kyotaro Horiguchi, Fujii Masao) (13)</li>
<p>
以前は、WALアーカイブが有効になっていると、スタンバイが新しいタイムラインで実行されているプライマリを追跡できず「ERROR: requested WAL segment ... has already been removed」などのエラーが発生する可能性がありました。
</p>
<li>論理デコード用に新しいスナップショットを送信する際の、walsenderプロセスのメモリリークが修正されました。 (Amit Kapila) (13)(12)(11)(10)(9.6)(9.5)</li>
<li>論理レプリケーション中にパーティションテーブルのルートを介して行の変更を送信する際の、walsenderプロセスのリレーションキャッシュの解放漏れが修正されました。 (Amit Langote, Mark Zhao) (13)</li>
<li>レプリケーション終了後に追加のコマンドを受け入れるように walsenderプロセスが修正されました。 (Jeff Davis) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
pg_basebackup 実行時にアサート失敗が生じる問題が報告されました。
</p>
<li>ホットスタンバイのバックエンドと startup(WAL適用)プロセスの間のデッドロックを検出するようになりました。 (Fujii Masao) (13)(12)(11)(10)(9.6)</li>
<p>
startupプロセスはデッドロックの検出処理を行っていないため、startupプロセスが最後に循環待機に参加した場合は、デッドロックが検出されない可能性がありました。
</p>
<li>HOTチェインを参照するインデックスエントリの削除中にリカバリの競合を検出できない問題が修正されました。 (Peter Geoghegan) (13)(12)</li>
<p>
以前は HOTチェインを辿るのに失敗して古すぎるトランザクションID限界を計算してしまい、ホットスタンバイでリカバリ競合を誤って処理する可能性がありました。ほとんどの場合、正しいトランザクションID限界は HOTチェインを調べなくとも取得できるため、このバグによる影響は限定的です。
</p>
<li>krb_server_keyfileパラメータ値が空でない場合は、常にサーバの KRB5_KTNAME環境変数による設定を上書きするようになりました。 (Tom Lane) (13)(12)</li>
<p>
以前は、どちらの設定が優先されるかはクライアントが GSS暗号化を要求するかによって異っていました。
</p>
<li>pg_hba.confファイルに一致するエントリがないときのログメッセージに、GSS暗号化が有効化されているかを詳細情報を含めるようになりました。 (Kyotaro Horiguchi, Tom Lane) (13)(12)</li>
<p>
hostgssenc または hostnogssenc のエントリが存在する場合は関連データがログメッセージに含まれます。
</p>
<li>サーバの GSS暗号化対応に関する様々な問題が修正されました。 (Tom Lane) (13)(12)</li>
<p>
GSS暗号化接続では GSS認証しか使用できないという無意味な制限が解除されました。GSS暗号化情報が接続認証時のログメッセージに追加されました。
</p>
<p>
共有メモリの必要サイズを計算するときに GSS暗号化関連の領域を含めるようになりました。以前は max_connectionsパラメータの値を非常に大きくした場合に問題が発生する可能性がありました。
</p>
<p>
復旧不能な GSS暗号化エラーを報告するときの無限再帰が回避されました。
</p>
<li>サーバが smart または fast モードで停止を開始するとき、バックグラウンドワーカに対する保留中の要求をキャンセルするようになりました。 (Tom Lane) (13)(12)(11)(10)</li>
<p>
以前は、停止直前にバックグラウンドワーカを要求したプロセスが無限に待機し、停止が完了しなくなる競合状態が発生していました。
</p>
<li>recovery_target_xidパラメータ値を解析する際の移植性の問題が修正されました。 (Michael Paquier) (13)(12)(11)(10)(9.6)</li>
<p>
指定されるトランザクションID はエポックを含めて 64ビット幅になりえますが、strtoul() 関数で解析されていたため、long型が 32ビットのプラットフォーム（Windows など）で不正な値としてエラーが発生していました。
</p>
<li>シングルユーザモードではパラレルインデックス作成が機能しないため、使用しないようになりました。 (Yulin Pei) (13)(12)(11)</li>
<pre>backend&gt; SET log_min_messages TO debug5;
backend&gt; CREATE INDEX ON t (c);

(修正前)
DEBUG:  building index "t_c_idx" on table "t" with request for 2 parallel workers

(修正後)
DEBUG:  building index "t_c_idx" on table "t" serially
</pre>
<li>インデックスの AM が複数列インデックスに対応していなくてもINCLUDE句に対応できるようになりました。 (Tom Lane) (13)(12)(11)</li>
<li>ベースバックアップを取得するとき、バックアップマニフェストが不要な場合にSHA256ハッシュを初期化しないようになりました。 (Michael Paquier) (13)</li>
<p>
FIPSモードの OpenSSLを使用する場合、SHA256ハッシュは拒否され、エラーが発生します。エラーを解消するには EVPハッシュへの書き換えが必要ですが、マイナーリリースでは互換性を維持するためにできません。この修正により、--no-manifest オプションを指定すれば、そのような場合でもベースバックアップを取得できます。
</p>
<li>STRICTでないデシリアライズ関数を指定した集約関数のパラレル処理中でアサート失敗が回避されました。 (Andrew Gierth) (13)(12)(11)</li>
<p>
そのような集約関数は PostgreSQL本体には存在しませんが、PostGIS などの一部の拡張では提供されています。いずれにしてもアサートを有効にしたビルドでなければ影響はありません。
</p>
<li>pg_get_functiondef() で、TRANSFORMオプションを伴う関数の検査時におけるアサート失敗が回避されました。 (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
pg_get_functiondef() は psql で関数定義を出力するときなどに使われます。
</p>
<pre>（他に以下のようなフォーマットの乱れも生じました）
db=# CREATE FUNCTION f(bool) RETURNS void AS $$
   $$ LANGUAGE plperl TRANSFORM FOR TYPE bool;

（修正前）
db=# \sf f
CREATE OR REPLACE FUNCTION public.f(boolean)
 RETURNS void

 TRANSFORM FOR TYPE boolean LANGUAGE plperl
AS $function$
$function$

（修正後）
=# \sf f
CREATE OR REPLACE FUNCTION public.f(boolean)
 RETURNS void
 TRANSFORM FOR TYPE boolean
 LANGUAGE plperl
AS $function$
   $function$
</pre>
<li>PL/pgSQL の CALL文でデータ構造の誤った割り当てが修正されました。 (Tom Lane) (13)(12)(11)</li>
<p>
以前はプロシージャ内で INOUT引数を持つ別のプロシージャを呼び出すと、呼び出し先で COMMIT または ROLLBACK 文を実行した場合にエラーになりました。
</p>
<pre>（障害動作例）
db=# CREATE PROCEDURE p1(INOUT a int) LANGUAGE plpgsql AS $$
       BEGIN COMMIT; a := 1; END; $$;
db=# CREATE PROCEDURE p2() LANGUAGE plpgsql AS $$
       DECLARE a int := 2;
       BEGIN CALL p1(a); END; $$;
db=# CALL p2();
ERROR:  unsupported target type: 0
CONTEXT:  PL/pgSQL function p2() line 5 at CALL
</pre>
<li>libpq で GSS暗号化接続の後に SSL暗号化接続を試すようになりました。 (Tom Lane) (13)(12)</li>
<p>
以前は GSS暗号化接続を確立した後、認証中に失敗した場合、SSL暗号化接続を試すことなく、非暗号化接続にフォールバックしていました。これにより、予期しない接続エラーが発生したり、暗号化が期待される場所で黙って暗号化されていなかったりする可能性がありました。
</p>
<li>libpq の PQconndefaults() 関数が channel_binding接続パラメータの正しいデフォルト値を返すようになりました。 (Daniele Varrazzo) (13)</li>
<p>
以前は NULL を返していました。
</p>
<li>psql の \connect コマンドが引数の接続文字列にパスワードを指定できるようになりました。 (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
以前は機能していましたが、最近のバグ修正でパスワード指定が無視され、パスワード入力が求められるようになっていました。
</p>
<li>psql の \dコマンドで、列のデフォルト値が切り捨て表示されないようになりました。 (Tom Lane) (13)(12)</li>
<p>
以前は、128 文字で勝手に切り捨てられていました。
</p>
<pre>=# CREATE TABLE t (c text DEFAULT '1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890');
CREATE TABLE

(修正前)
=# \d t
                                                                            Table "public.t"
 Column | Type | Collation | Nullable |                                                             Default
--------+------+-----------+----------+----------------------------------------------------------------------------------------------------------------------------------
 c      | text |           |          | '1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567

(修正後)
=# \d t
                                                                                 Table "public.t"
 Column | Type | Collation | Nullable |                                                                  Default
--------+------+-----------+----------+--------------------------------------------------------------------------------------------------------------------------------------------
 c      | text |           |          | '1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890'::text
</pre>
<li>psql の \help コマンドの様々なバグが修正されました。 (Kyotaro Horiguchi, Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
以前は引数が複数の単語からなる場合に最初の単語を使ってヘルプが見つけられませんでした。例えば、\help RESET ALL で RESET文のヘルプを表示できませんでした。また、必要な場合にページャを呼び出せないことがよくあり、メモリリークも発生していました。
</p>
<pre>(修正前)
db=# \help RESET ALL
No help available for "RESET ALL".
Try \h with no arguments to see available help.

(修正後)
db=# \help RESET ALL
Command:     RESET
Description: restore the value of a run-time parameter to the default value
Syntax:
RESET configuration_parameter
RESET ALL

URL: https://www.postgresql.org/docs/13/sql-reset.html
</pre>
<li>pg_dump での継承された生成列のダンプが修正されました。 (Peter Eisentraut) (13)(12)</li>
<p>
以前の動作ではリストア時に無害ですが余計なエラーが発生していました。
</p>
<pre>（該当するテーブル定義例）
CREATE TABLE t61p (c1 int, c2 int GENERATED ALWAYS AS (c1 * 2) STORED);
CREATE TABLE t61c () INHERITS (t61p);

（リストア時のエラー例）
pg_restore: from TOC entry 3432; 2604 33854 DEFAULT t61c c2 postgres
pg_restore: error: could not execute query: ERROR:  column "c2" of relation "t61c" is a generated column
Command was: ALTER TABLE ONLY public.t61c ALTER COLUMN c2 SET DEFAULT (c1 * 2);
</pre>
<li>pg_dump でリストアスクリプトが ALTER PUBLICATION ADD TABLE コマンドをパブリケーションの所有者として実行するようになりました。 (Tom Lane) (13)(12)(11)(10)</li>
<p>
（11.x 以降バージョンでは）同様に ALTER INDEX ATTACH PARTITION コマンドもパーティションインデックスの所有者として実行するようになりました。
</p>
<p>
以前は、これらのコマンドはリストアスクリプトを開始したロールによって実行されていました。これらは通常動作しますが、場合によってはそのロールが十分な権限を持っていない可能性がありました。
</p>
<li>拡張の初期権限で WITH GRANT OPTION を扱うように pg_dump が修正されました。 (Noah Misch) (13)(12)(11)(10)(9.6)</li>
<p>
拡張のスクリプトがオブジェクトを作成し、そのオブジェクトに GRANT OPTIONで権限を付与した場合、後にユーザがそのような権限を取り消すとpg_dump はその状況を再現するために誤ったSQLを生成してしまいます。
</p>
<p>
ただし、この誤動作に該当する拡張は今日ほとんどありません。
</p>
<li>pg_rewind でスタンバイサーバを巻き戻す際にすべてのWALを考慮するようになりました。 (Ian Barwick, Heikki Linnakangas) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
巻き戻しが必要であるときに、巻き戻し不要と判断するケースがありました。
</p>
<li>pgbench で変数名の最初の文字として数字の使用が禁止されました。 (Fabien Coelho) (13)(12)(11)</li>
<p>
これにより、変数を「12:34」のような文字列を含むタイムスタンプのリテラル値に代入しようとする動作を防ぎます。
</p>
<li>一部のクライアントプログラムからの接続失敗エラーメッセージで正しいデータベース名が報告されるようになりました。 (Alvaro Herrera) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
データベース名がコマンドラインで指定されるのではなくデフォルトで設定されていた場合、pg_dumpall、pgbench、oid2name、vacuulo は、接続失敗後に誤解を招くエラーメッセージを出力していました。
</p>
<pre>（データベース名が空欄のエラーメッセージ例）
[user1@host1 ~]$ pgbench
pgbench: error: connection to database "" failed: FATAL:  role "user1" does not exist
</pre>
<li>contrib/auto_explain のメモリリークが修正されました。 (Japin Li) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
EXPLAIN 出力を生成中に消費されたメモリは、現在のトランザクションが終了するまで(最上位の文の場合)、または周囲の文が終了するまで(入れ子になった文の場合)解放されませんでした。これは log_nested_statements が有効な場合に特に問題でした。
</p>
<li>contrib/postgres_fdw でユーザマッピングや外部サーバオブジェクトが削除された場合に、リモートサーバへのオープンしている接続がクローズされずに残る動作が回避されました。 (Bharath Rupireddy) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
これからは削除されたユーザーマッピングや外部サーバに依存する接続は切断されて参照できなくなります。以前はローカルセッションの間は何であれ維持されていました。
</p>
<li>contrib/postgres_fdw の誤ったアサーションが修正されました。 (Etsuro Fujita) (13)</li>
<li>contrib/pgcrypto で、OpenSSL の EVP関数からのエラー応答を確認するようになりました。 (Michael Paquier) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
実際にはここでエラーは発生しないと考えられますが、この変更により静的分析ツールからの警告が表示されなくなりました。
</p>
<li>プレウォームが完了する前にクラスタがシャットダウンされた場合について、contrib/pg_prewarm がより頑健になりました。 (Tom Lane) (13)(12)(11)</li>
<p>
以前は、autoprewarm はこれまでにロードできたブロック番号のみでステータスファイルに書き換えていました。そのため、次回の起動時にプレウォーム機能が大幅に無効化されてしまう可能性がありました。本修正により、最初のロードパスが完了するまでステータスファイルの更新を抑制するようになりました。
</p>
<li>contrib/pg_trgm の GiSTインデックスのサポートにおいて、picksplit が正確に 2つのインデックス項目で呼び出された場合におけるクラッシュが回避されるようになりました。 (Andrew Gierth, Alexander Korotkov) (13)(12)(11)(10)(9.6)(9.5)</li>
<li>contrib/pg_prewarm および contrib/postgres_fdw における誤ったタイムアウトの計算が修正されました。 (Alexey Kondratov, Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
contrib/pg_prewarm の autoprewarm 親プロセスのメインループは、望ましいスリープ時間を 1000分の 1 に過小評価しており、意図したよりもはるかに多くの CPUを消費していました。リモートサーバからの結果を待つ場合、contrib/postgres_fdw は、希望するタイムアウト時間を 1000倍に過大評価していました。（ただしこの誤りは 60秒の上限を設けていたことで軽減されていました）
</p>
<p>
これらのエラーはどちらも、秒とマイクロ秒をミリ秒に誤って変換することに起因していました。新しい API TimestampDifferenceMilliseconds() を導入して、将来的にこれをより簡単に正しく取得できるようにしました。
</p>
<li>macOS で PG_SYSROOT を選択する際の configure のヒューリスティックが改善されました。 (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
この新しい方式により、Xcode が基盤となるオペレーティングシステムよりも新しい場合に、望ましい結果が得られる可能性が高くなります。OS のバージョンと一致しない sysroot を選択すると、実行可能ファイルが機能しなくなるかもしれません。
</p>
<li>macOS 上でビルドする場合は、コンパイルステップと同様にリンクステップでも -isysroot を指定するようになりました。 (James Hilliard) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
これにより、Xcode がオペレーティングシステムと同期していない場合の結果も同様に改善されます。
</p>
<li>LLVM 11 および LLVM 12 と互換性があるように JITコンパイルが修正されました。 (Andres Freund) (13)(12)(11)</li>
<li>JIT式のコンパイルでブーリアン変数への参照が誤って処理される可能性があり、修正されました。 (Andres Freund) (13)(12)(11)</li>
<p>
これに起因する障害報告は確認されていませんが、一部のアーキテクチャでは問題が発生する可能性がありました。
</p>
<li>ICU 68 以降でのコンパイル失敗が修正されました。 (Tom Lane) (13)(12)(11)</li>
<li>パーティションインデックス作成時に、NULL のソースポインタとコピー数がゼロの memcpy() 実行を回避するようになりました。 (Alvaro Herrera) (13)(12)(11)</li>
<p>
このような呼び出し自体が問題を引き起こすことは知られていませんが、一部のコンパイラは memcpy() の引数が決して NULL ではないと仮定しているため、近くのコードが正しく最適化されない可能性があります。
</p>
<li>タイムゾーンデータファイルが tzdata release 2021a に更新されました。 (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
ロシア（ボルゴグラードゾーン）と南スーダンでの夏時間法の変更に加えて、オーストラリア、バハマ、ベリーズ、バミューダ、ガーナ、イスラエル、ケニア、ナイジェリア、パレスチナ、セーシェル、バヌアツの歴史的修正が含まれます。
</p>
<p>
特に、Australia/Currie は、Australia/Hobart と同じになるように修正されました。
</p>
<li>パラレルクエリを頻繁に使用しているときに、DSMスロットを使い切ることがないように設定が調整されました。 (Thomas Munro) (12)(11)(10)</li>
<p>
ソースコード内の定数値が変更されました。
</p>
<li>LISTEN/NOTIFY のキュー処理で最近組み込まれた競合状態が修正されました。 (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
新たに LISTEN しているバックエンドが、切り捨てられている途中のSLRUページを読み取ろうとして、エラーが発生する可能性がありました。
</p>
<p>
キューの末尾ポインタがバックエンドのキュー位置と等しくない値に設定される可能性があり、その結果、キュー切り捨てロジックが実際には無効になります。その後 NOTIFY の継続的な使用は、キューがいっぱいの警告を発生させ、最終的にはサーバが再起動されるまで NOTIFY を送ることができなくなりました。
</p>
</ol>

<div></div>
<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>ロジカルレプリケーションの紹介 (1)</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/logical-replication-1/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Thu, 21 Jan 2021 01:43:14 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 10]]></category>
		<category><![CDATA[ロジカルレプリケーション]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=6683</guid>

					<description><![CDATA[更新日:2025年5月1日 本記事では、PostgreSQL 10 より導入された新たなレプリケーション方式「ロジカルレプリケーション」の概要、構築方法について紹介します。 ロジカルレプリケーションの概要 ロジカルレプリ ...]]></description>
										<content:encoded><![CDATA[<p>更新日:2025年5月1日</p>
<p>本記事では、PostgreSQL 10 より導入された新たなレプリケーション方式「ロジカルレプリケーション」の概要、構築方法について紹介します。</p>
<p><span id="more-6683"></span></p>
<h2>ロジカルレプリケーションの概要</h2>
<h3>ロジカルレプリケーションとは</h3>
<p>ロジカルレプリケーションは PostgreSQL 10 より導入されたレプリケーションの機能です。レプリケーション元となる PostgreSQL でパブリケーション（publication・発行者）を作成し、レプリケーション先となる PostgreSQL でサブスクリプション（subscription・購読者）を作成することで、レプリケーション機能が有効となります。また、レプリケーション元の PostgreSQL をパブリッシャ、レプリケーション先の PostgreSQL をサブスクライバと呼びます。まずはストリーミングレプリケーションとの違いを見ながらロジカルレプリケーションの概要をご説明いたします。</p>
<p>※本記事では PostgreSQL 12 を想定しています。</p>
<h3>ロジカルレプリケーションとストリーミングレプリケーションの違い</h3>
<p>ロジカルレプリケーションとストリーミングレプリケーションの違いは以下のとおりです。</p>
<table>
<thead>
<tr>
<th>項目</th>
<th>ロジカルレプリケーション</th>
<th>ストリーミングレプリケーション</th>
</tr>
</thead>
<tbody>
<tr>
<th>転送するデータ</th>
<td>WALレコードに書き込まれた「どのような操作を行ったか」という論理的な情報</td>
<td>WAL レコード</td>
</tr>
<tr>
<th>データ転送のタイミング</th>
<td>COMMIT 完了時に送信</td>
<td>WAL レコードが発生する都度送信</td>
</tr>
<tr>
<th>送信に関連するプロセス</th>
<td>wal_sender</td>
<td>wal_sender</td>
</tr>
<tr>
<th>受信に関連するプロセス</th>
<td>logical replication launcher, logical replication worker</td>
<td>walreceiver, startup</td>
</tr>
<tr>
<th>レプリケーションの単位</th>
<td>テーブル単位、データベース単位</td>
<td>データベースクラスタ単位</td>
</tr>
<tr>
<th>レプリケーションされない操作</th>
<td>TRUNCATE(*1)以外の DDL 文</td>
<td>なし</td>
</tr>
<tr>
<th>レプリケーションされないオブジェクト</th>
<td>通常のテーブル以外(*2)</td>
<td>UNLOGGED テーブル</td>
</tr>
<tr>
<th>異なるメジャーバージョンでも動作できるか</th>
<td>できる</td>
<td>できない</td>
</tr>
<tr>
<th>異なる OS、アーキテクチャでも動作できるか</th>
<td>できる</td>
<td>できない</td>
</tr>
<tr>
<th>同期／非同期レプリケーション</th>
<td>できる</td>
<td>できる</td>
</tr>
<tr>
<th>スタンバイへの参照</th>
<td>できる</td>
<td>設定次第でできる</td>
</tr>
<tr>
<th>スタンバイへの更新</th>
<td>できる</td>
<td>できない</td>
</tr>
<tr>
<th>スタンバイでトリガ起動</th>
<td>できる</td>
<td>できない</td>
</tr>
</tbody>
</table>
<p>(*1) PostgreSQL 10 では TRUNCATE はレプリケーションされませんので TRUNCATE の代わりに DELETE で削除する必要があります。<br />
(*2) シーケンス、ラージオブジェクト、ビューなど。</p>
<h3>ロジカルレプリケーションを活用できる状況</h3>
<p>上記表でご確認いただいたように、下記のようなことを行いたい場合、ロジカルレプリケーションが役立つのではないかと考えられます。</p>
<ul>
<li>テーブル単位でのレプリケーションを行いたい</li>
<li>メジャーバージョンが異なる PostgreSQL 間でのレプリケーションを行いたい</li>
<li>サブスクライバ側でデータを受け取った際に、トリガを起動させたい</li>
<li>ストリーミングレプリケーションで発生する「マスタの更新と、スタンバイの参照の競合」を回避したい</li>
</ul>
<h2>ロジカルレプリケーション環境の構築</h2>
<p>実際にパブリケーションとサブスクリプションを作成して、ロジカルレプリケーションが動作する環境を構築していきます。</p>
<p>以降の解説内では</p>
<ul>
<li>パブリッシャとなる PostgreSQL のサーバ名を first_server、データベース名を first</li>
<li>サブスクライバとなる PostgreSQL のデータベース名を second</li>
<li>ロジカルレプリケーション用のユーザ名を logi_user</li>
</ul>
<p>としています。</p>
<p>そのため、</p>
<ul>
<li>first=# で始まる SQL はパブリッシャで実行するコマンド</li>
<li>second=# で始まる SQL はサブスクライバで実行するコマンド</li>
</ul>
<p>となります。</p>
<h3>postgresql.conf の設定</h3>
<p>ロジカルレプリケーションを機能させるには、パブリッシャの wal_level が logical である必要があります。wal_level のデフォルト値は replica ですので、パブリッシャの postgresql.conf で下記のように wal_level を logical に変更します。</p>
<pre>wal_level = 'logical'
</pre>
<p>その他、ロジカルレプリケーションに関連するパラメータは</p>
<ul>
<li>max_logical_replication_workers</li>
<li>max_replication_slots</li>
<li>max_sync_workers_per_subscription</li>
<li>max_wal_senders</li>
<li>max_worker_processes</li>
</ul>
<p>があります。機能させたいロジカルレプリケーションの数によっては、上記パラメータの値を調整する必要があります。それぞれのパラメータに必要な設定値は下記マニュアルをご確認ください。</p>
<p>[ 参考マニュアル &#8211; <a href="https://www.sraoss.co.jp/PostgreSQL/Manual/document/12/logical-replication-config.html">論理レプリケーション 構成設定</a> ]</p>
<h3>pg_hba.conf の設定</h3>
<p>サブスクライバの PostgreSQL からパブリッシャの PostgreSQL に接続できるように、パブリッシャの pg_hba.conf に設定を加えます。</p>
<pre>host  first           logi_user           xxx.xxx.xxx.xxx/32      md5
</pre>
<h3>パブリケーションの作成</h3>
<p>レプリケーション元となるパブリッシャで、パブリケーションを作成します。パブリケーションには、1つのテーブルだけでなく、複数のテーブルを指定できますので、複数のテーブルをまとめてレプリケーションできます。また、オプションでロジカルレプリケーションの対象とする操作（INSERT、UPDATE、DELETE、TRUNCATE）を指定できます。たとえば、INSERT のみをレプリケーションさせることができます。</p>
<p>ただし、UPDATE と DELETE をレプリケーションするためには、パブリッシャのテーブルの REPLICA IDENTITY （行を一意に特定できるカラムの情報）の設定が必要となります。テーブルに主キーが存在する場合は自動的に REPLICA IDENTITY に主キーが設定されます。主キーが存在しないテーブルに REPLICA IDENTITY の指定（USING INDEX または FULL）がない場合、UPDATE および DELETE を実行した際に、実行エラーが発生しますのでご注意ください。</p>
<h4>ロジカルレプリケーション用のテーブル作成</h4>
<p>ロジカルレプリケーションを行うためのテーブル logical_table をパブリッシャに作成します。</p>
<pre>first=# CREATE TABLE logical_table
        (id INTEGER PRIMARY KEY, no INTEGER , data TEXT);
</pre>
<h4>パブリケーションの作成例</h4>
<p>作成したテーブルに対して行った操作をサブスクライバに伝搬させるためのパブリケーションを作成します。パブリケーションの作成例を下記に記載します。</p>
<pre>-- logical_table に対する操作を伝搬させるパブリケーションの作成
first=# CREATE PUBLICATION logical_pub FOR TABLE logical_table;

-- すべてのテーブルに対する操作を伝搬させるパブリケーションの作成
first=# CREATE PUBLICATION logical_pub_all_table FOR ALL TABLES;

-- logical_table に対する INSERT を伝搬させるパブリケーションの作成
first=# CREATE PUBLICATION logical_pub_insert_only
        FOR TABLE logical_table WITH (publish = 'insert');

-- パブリケーションの枠だけ作成
first=# CREATE PUBLICATION logical_pub_non_table ;
</pre>
<p>※各パラメータの詳細は下記マニュアルをご確認ください。</p>
<p>[ 参考マニュアル &#8211; <a href="https://www.sraoss.co.jp/PostgreSQL/Manual/document/12/sql-createpublication.html">CREATE PUBLICATION</a> ]</p>
<h4>パブリケーションの確認</h4>
<p>pg_publication システムカタログを参照することで、作成されているパブリケーションを確認できます。</p>
<pre>first=# SELECT * FROM pg_publication;

  oid  |    pubname    | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate
-------+---------------+----------+--------------+-----------+-----------+-----------+-------------
 16651 | logical_pub   |       10 | f            | t         | t         | t         | t
(1 行)

</pre>
<p>psql であればメタコマンド <code>\dRp</code> で確認できます。</p>
<pre>first=# \dRp
                               パブリケーション一覧
    名前     |  所有者  | 全テーブル | Insert文 | Update文 | Delete文 | Truncate文
-------------+----------+------------+----------+----------+----------+------------
 logical_pub | postgres | f          | t        | t        | t        | t
(1 行)
</pre>
<h4>パブリケーションとテーブルのマッピングを確認する</h4>
<p>pg_publication_tables システムカタログで、パブリケーションとそれに含まれるテーブルのマッピングを確認できます。</p>
<pre>first=# SELECT * FROM pg_publication_tables;

    pubname   | schemaname | tablename
--------------+------------+---------------
 logical_pub  | public     | logical_table
(1 行)
</pre>
<p>上記の出力から、logical_pub というパブリケーションに logical_table テーブルがマッピングされていることが分かります。</p>
<p>パブリケーションとテーブルのマッピングを、名称ではなく oid で確認するには pg_publication_rel システムカタログを参照します。</p>
<pre>first=# select * from pg_publication_rel;
  oid  | prpubid | prrelid
-------+---------+---------
 16665 |   16664 |   16658
(1 行)
</pre>
<h3>サブスクリプションの作成</h3>
<p>パブリケーションを作成できたら、今度はパブリケーションから送られる更新情報を受け取るためのサブスクリプションをサブスクライバに作成します。</p>
<h4>ロジカルレプリケーション用のテーブル作成</h4>
<p>サブスクライバにもパブリッシャと同様のテーブルを作成します。これがロジカルレプリケーションの受け口になるテーブルです。</p>
<p>サブスクライバのテーブルは、パブリッシャのテーブルと</p>
<ul>
<li>スキーマ名</li>
<li>テーブル名</li>
<li>列名</li>
</ul>
<p>が同じである必要があります。サブスクライバのテーブル定義はパブリッシャのテーブルと完全に同一である必要はなく、サブスクライバのテーブル定義がパブリッシャのテーブル定義を内包しているのであれば、ロジカルレプリケーションが行われます。</p>
<p>下記の作成例では、パブリッシャのテーブル定義に加えて data2 カラムが存在しますが、id, no, data カラムがパブリッシャのテーブル定義と同一なためロジカルレプリケーションが行われます。</p>
<pre>second=# CREATE TABLE logical_table
         (id INTEGER PRIMARY KEY, no INTEGER, data TEXT, data2 TEXT);
</pre>
<h4>サブスクリプションの作成例</h4>
<p>パブリッシャへの接続文字列などを指定して、サブスクリプションを作成します。サブスクリプションの作成例を下記に記載します。</p>
<pre>-- パブリッシャの logical_pub パブリケーションに対する操作を受け取るための
-- サブスクリプションを作成
second=# CREATE SUBSCRIPTION logical_sub
         CONNECTION 'host=first_server port=5432 user=logi_user dbname=first'
         PUBLICATION logical_pub;

-- パブリッシャに作成するレプリケーションスロット名（slot_name）を指定して、
-- サブスクリプションを作成
-- (slot_name を指定しない場合、レプリケーションスロット名にはサブスクリプション名が設定されます)
second=# CREATE SUBSCRIPTION logical_sub
         CONNECTION 'host=first_server port=5432 user=logi_user dbname=first'
         PUBLICATION logical_pub WITH (slot_name = 'logical_sub_slot');

-- パブリッシャに通知するアプリケーション名（application_name）を指定して、
-- サブスクリプションを作成
-- (application_name を指定しない場合、アプリケーション名にはサブスクリプション名が設定されます)
second=# CREATE SUBSCRIPTION logical_sub
         CONNECTION 'host=first_server port=5432 user=logi_user dbname=first application_name=logical_sub_app'
         PUBLICATION logical_pub;

-- コミットの同期モード（synchronous_commit）を指定して、サブスクリプションを作成
-- （postgresql.conf で設定した synchronous_commit よりも優先されます）
-- （synchronous_commit を指定しない場合、off が設定されます）
second=# CREATE SUBSCRIPTION logical_sub
         CONNECTION 'host=first_server port=5432 user=logi_user dbname=first'
         PUBLICATION logical_pub WITH (synchronous_commit = 'on');
</pre>
<p>※上記以外にも指定できるパラメータやオプションが存在します。詳細はマニュアルをご確認ください。</p>
<p>[ 参考マニュアル &#8211; <a href="https://www.sraoss.co.jp/PostgreSQL/Manual/document/12/sql-createsubscription.html">CREATE SUBSCRIPTION</a> ]</p>
<h4>作成したサブスクリプションの確認</h4>
<p>作成したサブスクリプションの情報は pg_subscription を参照することで確認できます。</p>
<pre>second=# SELECT * FROM pg_subscription;

-[ RECORD 1 ]---+--------------------------------------------------------------------------------------------
oid             | 24704
subdbid         | 13266
subname         | logical_sub
subowner        | 10
subenabled      | t
subconninfo     | host=first_server port=5432 user=logi_user dbname=first application_name=logical_sub_app
subslotname     | logical_sub_slot
subsynccommit   | on
subpublications | {logical_pub}
</pre>
<p>psql であればメタコマンド <code>\dRs</code> で確認できます。</p>
<pre>second=# \dRs
                サブスクリプション一覧
    名前     |  所有者  | 有効状態 | パブリケーション
-------------+----------+----------+------------------
 logical_sub | postgres | t        | {logical_pub}
(1 行)
</pre>
<p>サブスクリプションのレプリケーション状態は pg_stat_subscription を参照することで確認できます。</p>
<pre>second=# SELECT * FROM pg_stat_subscription;

-[ RECORD 1 ]---------+------------------------------
subid                 | 24704
subname               | logical_sub
pid                   | 9374
relid                 |
received_lsn          | 6/B9064B18
last_msg_send_time    | 2020-10-14 16:43:37.585108+09
last_msg_receipt_time | 2020-10-14 16:43:37.586771+09
latest_end_lsn        | 6/B9064B18
latest_end_time       | 2020-10-14 16:43:37.585108+09
</pre>
<p>また、サブスクリプションとテーブルのマッピングは pg_subscription_rel で確認できます。</p>
<pre>second=# SELECT * FROM pg_subscription_rel;

 srsubid | srrelid | srsubstate | srsublsn
---------+---------+------------+----------
   24704 |   24679 | d          |
(1 行)
</pre>
<p>上記のとおり、pg_subscription_rel の中にはテーブルの名前ではなく oid で情報が保持されています。パブリケーションと違い、現時点でマッピングの情報を名称で確認できるシステムカタログはないようです。サブスクリプションとテーブル名のマッピングは pg_subscription と pg_class を合わせて参照することで確認できます。</p>
<pre>second=# SELECT
    pg_subscription.subname
  , pg_class.relname
  , pg_subscription_rel.srsubstate
  , pg_subscription_rel.srsublsn
FROM
  pg_subscription_rel
    INNER JOIN pg_subscription
            ON pg_subscription_rel.srsubid = pg_subscription.oid
    INNER JOIN pg_class
            ON pg_subscription_rel.srrelid = pg_class.oid
;

   subname   |    relname    | srsubstate | srsublsn
-------------+---------------+------------+----------
 logical_sub | logical_table | d          |
(1 行)
</pre>
<h4>初期データコピー</h4>
<p>サブスクリプションを作成した時点で、初期コピーと呼ばれる「パブリッシャのテーブルからサブスクライバのテーブルへのデータコピー処理」が実行されます。</p>
<pre>-- サブスクリプション作成前の logical_table の中身（初期コピー前は 0 件）
second=# =# SELECT * FROM logical_table;
 id | no | data | data2
----+----+------+-------
(0 行)

-- サブスクリプション作成（初期コピー実施）
second=# CREATE SUBSCRIPTION logical_sub
         CONNECTION 'host=first_server port=5432 user=logi_user dbname=first'
         PUBLICATION logical_pub;
CREATE SUBSCRIPTION

-- サブスクリプション作成後の logical_table の中身
-- （パブリッシャの logical_table のデータがコピー）
second=# SELECT * FROM logical_table;
 id | no |  data  | data2
----+----+--------+-------
  1 |  1 | 北海道 |
  2 |  2 | 青森県 |
  3 |  3 | 岩手県 |
  : |  : | 　:　 |
  : |  : | 　:　 |
 47 | 47 | 沖縄県 |
(47 行)

</pre>
<p>また、この初期コピーの際に、コピーされるパブリッシャのデータとサブスクライバの既存のデータが競合し、一意制約エラーの発生する可能性があります。</p>
<p>これは初期コピーが「差分のみを追加する」などの制御を行わずに、単純に「パブリッシャのテーブルのデータを、そのままサブスクライバのテーブルへ追加する」ためです。</p>
<pre># データ競合時のエラーメッセージ
2020-10-14 15:15:27.775 JST [8365](err_code=23505) ERROR:  duplicate key value violates unique constraint "logical_table_pkey"
2020-10-14 15:15:27.775 JST [8365](err_code=23505) DETAIL:  Key (id)=(1) already exists.
</pre>
<p>こういった場合、copy_data オプションに false を指定し、初期コピーを行わないことでエラーを回避できます。</p>
<pre>second=# CREATE SUBSCRIPTION logical_sub
         CONNECTION 'host=first_server port=5432 user=logi_user dbname=first'
         PUBLICATION logical_pub WITH (copy_data = false);
</pre>
<h3>サブスクリプションの有効／無効の切り替え</h3>
<p>サブスクリプションは有効／無効を切り替えることができます。そのため、ロジカルレプリケーションを一時的に中断したい場合でも、サブスクリプションを削除する必要がありません。</p>
<h4>サブスクリプションの無効化</h4>
<p>サブスクリプションを無効にします。無効化している間は、当然ですがパブリッシャで行った操作がサブスクライバへレプリケーションされなくなります。</p>
<pre>second=# ALTER SUBSCRIPTION logical_sub DISABLE;
</pre>
<h4>サブスクリプションの有効化</h4>
<p>サブスクリプションを有効にします。サブスクリプションを有効にした場合、無効化した時点からレプリケーションが行われます。そのため、サブスクリプションを有効化することで、無効化されている間に行った操作がサブスクライバへレプリケーションされます。</p>
<pre>second=# ALTER SUBSCRIPTION logical_sub ENABLE;
</pre>
<h2>まとめ</h2>
<p>以上、ロジカルレプリケーションの概要と基本的な使い方をご紹介させていただきました。次回以降では、ロジカルレプリケーションの機能を実現するプロセスについての解説や、カスケードレプリケーションの設定やコンフリクト発生時の解消方法などの運用に関する情報などをお伝えする予定です。</p>
<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 10.15 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/10-15/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Fri, 20 Nov 2020 02:02:51 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 10]]></category>
		<category><![CDATA[PostgreSQL 10.14]]></category>
		<category><![CDATA[PostgreSQL 10.15]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=6597</guid>

					<description><![CDATA[このリリースは 10.14 からの修正リリース（2020年11月12日リリース）です。 10.x からのアップデートではダンプ、リストアは不要です。 ただし、10.11よりも前のバージョンからアップデートする場合には、1 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 10.14 からの修正リリース（2020年11月12日リリース）です。</p>
<p>10.x からのアップデートではダンプ、リストアは不要です。<br />
ただし、10.11よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/10-11/">10.11 のリリース情報</a>も参照してください。</p>
<p><span id="more-6597"></span></p>
<h3>PostgreSQL 10.14 から 10.15 への変更点</h3>
<p>13.1、12.5、11.10、10.15、9.6.20、9.5.24 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>インデックス式およびマテリアライズドビュー定義内での、DECLARE CURSOR ... WITH HOLD と遅延トリガの駆動が禁止されました。  (Noah Misch) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
これらはアクセス制限の仕組みの抜け穴となっていて、テンポラリでない SQLオブジェクトを作る権限を持った攻撃者はスーパーユーザとして任意の SQL実行が可能でした。(CVE-2020-25695)
</p>
<p>
これからは該当する操作について、それぞれ以下のエラーが生じます。
</p>
<pre>
ERROR:  cannot create a cursor WITH HOLD within security-restricted operation

ERROR:  cannot fire deferred trigger within security-restricted operation
</pre>
<li>pg_dump、pg_restore、clusterdb、reindexdb、vacuumdb の各コマンドにおける複合的な接続文字列パラメータの使用方法について修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
pg_dump と pg_restore の -d パラメータや他コマンドの --maintenance-db パラメータには、単一のデータベース名ではなく、複合的な接続パラメータを含む接続文字列を与えることもできます。
</p>
<p>
これらのコマンドが、並列処理や複数データベース処理などで、追加的な接続を開始する必要がある場合、指定した接続文字列が無視されて、通常の接続パラメータ（データベース名、ホスト、ポート、ユーザ名）が使われていました。
</p>
<p>
デフォルトと異なる SSL や GSS のパラメータなど、接続文字列に何らか重要な情報が含まれている場合、この振る舞いのために接続失敗が生じる可能性がありました。さらに悪いことに、接続は成功するけれども意図通りに暗号化されていないというセキュリティ上の危険を伴う動作もあり得ました。(CVE-2020-25694)
</p>
<pre>
（以下コマンドで --jobs 指定があるとき失敗するという発生例が報告されました）
$ pg_dump --dbname="sslmode=verify-ca sslrootcert=server-ca.pem \
   sslcert=client-cert.pem sslkey=client-key.pem \
   hostaddr=1.2.3.4 user=postgres dbname=app" \
   --format=directory --file=dump.dat --jobs=3 
</pre>
<li>psqlの \connect コマンドが接続パラメータを再使用したとき、以前の接続文字列から上書きされていない全てのパラメータが確実に再使用されるようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
これまでは、デフォルトでない SSL や GSS のオプションなどのパラメータが無視されて再接続に失敗することがありました。さらに悪いことに、再接続は成功するけれども意図通り暗号化されず、セキュリティ上の危険を伴う動作もあり得ました。(CVE-2020-25694)
</p>
<li>psql の \gset コマンドが特別に扱われる変数を変更してしまう動作が防止されました。  (Noah Misch) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
PROMPT1 などのプロンプトの変数にはコマンド実行結果を含めることができるため、安全でないサーバから意図せぬ SQL実行結果が返ることで、クライアント側で任意のシェルコマンドが実行されてしまう危険がありました。(CVE-2020-25696)
</p>
<pre>
（特別に扱われる変数を上書きしてしまう動作例）
db1=# SELECT 'off' as "AUTOCOMMIT", '%`hostname`&gt; ' as "PROMPT1"; \gset
 AUTOCOMMIT |    PROMPT1
------------+---------------
 off        | %`hostname`&gt;
(1 row)

host1&gt; \echo :AUTOCOMMIT
off
host1&gt;
</pre>
<li>レプリケーションプロトコルの意図せぬ動作が修正されました。  (&Aacute;lvaro Herrera) (13)</li>
<p>
13.0 以降で wal sender は START_REPLICATION に対してコマンド完了イベントを二つ報告します。これはドキュメントに記載されておらず、明らかに意図されたものではありません。しかしながら、wal receiver が一部のコードパスで余分なイベントを必要とすることが判明したため、二つのコマンド完了イベントが返る動作を正として修正され、そのようにドキュメント記載されました。
</p>
<li>チェックポイント時に SLRUディレクトリが適切に fsync されることが保証されました。  (Thomas Munro) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
これは OS のクラッシュによるデータ損失を防止します。SLRUディレクトリとして、トランザクション制御に使われる pg_xact (pg_clog)、pg_commit_ts、pg_subtrans、共有行ロック制御に使われる pg_multixact などが該当します。
</p>
<li>BYPASSRLS属性を伴うユーザに対する ALTER ROLE が修正されました。  (Tom Lane, Stephen Frost) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
BYPASSRLS属性の変更はスーパーユーザによってのみ行えます。しかし、パスワード変更など、他の ALTER ROLE操作は、通常のパーミッション検査によって許可されるべきです。これまでは誤って、BYPASSRLS属性を持ったユーザに対するすべての変更にスーパーユーザ権限が必要となっていました。
</p>
<pre>
（修正前の動作例： BYPASSRLS属性があると自身のパスワード変更に失敗）
db1=# ALTER ROLE foo BYPASSRLS;
ALTER ROLE
db1=# \c db1 foo
You are now connected to database "db1" as user "foo".
db1=&gt; ALTER ROLE foo PASSWORD 'newpass';
ERROR:  must be superuser to change bypassrls attribute
</pre>
<li>子テーブルに対して ALTER TABLE ONLY ... DROP EXPRESSION が禁止されました。  (Peter Eisentraut) (13)</li>
<p>
これは生成列を通常の列にするコマンドですが、現在の実装では子テーブルに対して正しく処理できないため、当面は単にこれを禁止することになりました。
</p>
<li>ALTER TABLE ONLY ... ENABLE/DISABLE TRIGGER が子テーブルを再帰的に処理しないようになりました。  (&Aacute;lvaro Herrera) (13)(12)(11)</li>
<p>
これまで ONLYフラグが無視されていました。
</p>
<li>LOCK TABLE が自己参照ビューに対しても成功するようになりました。  (Tom Lane) (13)(12)(11)</li>
<p>
これまでは無限再帰を理由としたエラー(ERROR:  infinite recursion detected ...)が出ていましたが、禁止する実装上の理由はありませんでした。定義可能な自己参照ビューの pg_dump に失敗する問題が報告されていました。
</p>
<li>REINDEX CONCURRENTLY の前後でインデックス式のプランナ統計情報が維持されるようになりました。  (Michael Paquier, Fabr&iacute;zio de Royes Mello) (13)(12)</li>
<p>
これは CONCURRENTLY ではない通常の REINDEX と同じ動作です。
</p>
<li>REINDEX CONCURRENTLY からの誤った進捗報告が修正されました。  (Matthias van de Meent, Michael Paquier) (13)(12)</li>
<p>
pg_stat_progress_create_index ビューに異なるテーブルやインデックスのOID が現れる動作が報告されました。
</p>
<li>ルールや更新可能ビューを通して依存する列が更新されたときに、生成列が確実に更新されるようになりました。  (Tom Lane) (13)(12)</li>
<p>
以下のような定義のテーブルとビューに対して、
</p>
<pre>
CREATE TABLE t13 (id serial, idplus1 int GENERATED ALWAYS AS (id + 1) STORED);
CREATE VIEW v13 AS SELECT * FROM t13;
</pre>
<p>
以下のような更新に失敗する場合が報告されました。
</p>
<pre>
UPDATE v13 SET id = 1000 WHERE id = 1;
</pre>
<p>
更新可能ビューを通した更新による列指定トリガの駆動に失敗する可能性もあり、本修正はこちらにも対応しています。
</p>
<li>照合順序に依存したパーティション境界の式でのエラーが修正されました。  (Tom Lane) (13)(12)</li>
<p>
以下のように照合順序（COLLATE）によって結果が変わる式を指定すると、これまではエラーになっていました。これからは、定義時点のデフォルト照合順序で境界条件の式が評価されるようになります。
</p>
<pre>
（従来の動作例）
db1=# CREATE TABLE pt14 (b boolean, v text) PARTITION BY LIST (b);
db1=# CREATE TABLE pt14_1 PARTITION OF pt14 FOR VALUES IN ('foo' &lt; 'bar');
ERROR:  could not determine which collation to use for string comparison
HINT:  Use the COLLATE clause to set the collation explicitly.
</pre>
<li>テキスト配列のハッシュ作成がサポートされました。  (Peter Eisentraut) (13)(12)</li>
<p>
配列要素が照合順序に影響を受ける場合に配列のハッシュ作成が失敗していました。特に、テキスト配列の列をキーとしたハッシュパーティショニングの利用を妨げていました。
</p>
<p>
これまでは以下のように行を挿入した時点でエラーが発生していました。これからはデフォルトの照合順序が適用されてエラーが回避されます。
</p>
<pre>
db1=# CREATE TABLE pt15 (ta text[], v text) PARTITION BY HASH (ta);
db1=# CREATE TABLE pt15_0 PARTITION OF pt15 FOR VALUES
        WITH (MODULUS 2, REMAINDER 0);
db1=# CREATE TABLE pt15_1 PARTITION OF pt15 FOR VALUES
        WITH (MODULUS 2, REMAINDER 1);
db1=# INSERT INTO pt15 VALUES (ARRAY['abc'], 'val1');
ERROR:  could not determine which collation to use for string hashing
HINT:  Use the COLLATE clause to set the collation explicitly.
</pre>
<li>データ型の異なる日付時刻の比較で、内部オーバーフローが防止されました。  (Nikita Glukhov, Alexander Korotkov, Tom Lane) (13)</li>
<p>
date型と timestamp型の比較で、date型の値が timestamp の有効範囲を超える場合にエラーが生じていました。また、timestamp型 と timestamptz型の比較で、タイムゾーンを適用すると有効範囲を超える場合にもエラーが生じていました。
</p>
<p>
型キャストできない場合でも正しく比較ができるように修正されました。
</p>
<pre>
（修正前の動作: 修正後はいずれも true が返ります）
db1=# SELECT '2202020-10-05'::date &gt; '2020-10-05'::timestamp;
ERROR:  date out of range for timestamp
db1=# SET TimeZone = 'UTC-2';
db1=# SELECT '4714-11-24 BC'::date &lt; '2020-10-05'::timestamptz;
ERROR:  date out of range for timestamp
db1=# SELECT '4714-11-24 BC'::timestamp &lt; '2020-10-05'::timestamptz;
ERROR:  timestamp out of range
</pre>
<li>to_date() と to_timestamp() におけるマイナス年から紀元前日付への1年ずれた変換が修正されました。  (Dar Alathar-Yemen, Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
また、マイナス年と明示的な BC指定は打ち消し合って、紀元後の年になります。このことがドキュメントにも明記されました。
</p>
<pre>
（誤動作例: 正しくは「0001-01-01 BC」）
db1=# SELECT to_date('-1-01-01','yyyy-mm-dd');
    to_date
---------------
 0002-01-01 BC
(1 row)

（誤動作例: 修正後はマイナス年と BC が打ち消し合って紀元後の年になる）
db1=# SELECT to_timestamp('-44-02-01 11:12:13 BC', 'YYYY-MM-DD HH24:MI:SS BC');
          to_timestamp
---------------------------------
 0045-02-01 11:12:13+09:18:59 BC
(1 row)
</pre>
<li>jsonpath の .datetime() メソッドが ISO 8601 書式のタイムスタンプに対応しました。  (Nikita Glukhov) (13)</li>
<p>
これは SQL標準では必須ではありませんが、to_json() 関数は Javascript互換のtimestamp書式を生成するため、対応するのが適切と判断されました。
</p>
<p>
ISO 8601 書式は「T」を使った「2017-03-10T12:34:56+3:10」といったものです。
</p>
<li>archive_mode が 'always' であるときスタンバイサーバが WALタイムラインヒストリファイル（.historyファイル）をアーカイブするように修正されました。  (Grigory Smolkin, Fujii Masao) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
これまではプライマリサーバからストリーミングレプリケーションで取得した本ファイルをアーカイブしませんでした。その結果、スタンバイサーバの PITRリカバリに失敗する可能性がありました。
</p>
<li>kqueue() システムコールを使うプラットフォームで、早すぎる postmasterダウンを判定をするときの境界条件的な場合が修正されました。  (Thomas Munro) (13)</li>
<p>
postmasterダウン後の動作が適切ではありませんでした。
</p>
<li>ソートキーが揮発的な式であるときの、誤ったインクリメンタルソートのプランの生成を回避するように修正されました。  (James Coleman) (13)</li>
<p>
本障害により、SQL実行時に以下のエラーが出ることがありました。
</p>
<pre>
ERROR:  ORDER/GROUP BY expression not found in targetlist
</pre>
<li>プランナが GEQO によるプラン作成でパーティション毎の結合を検討するときにクラッシュする可能性があり、修正されました。  (Tom Lane) (13)(12)</li>
<li>TOASTデータの展開で無限ループや破損データ出力をする可能性があり、修正されました。  (Tom Lane) (13)</li>
<li>クリーンアップのみを行う VACUUM で、B-treeインデックスのエントリ数のカウントについて修正されました。  (Peter Geoghegan) (13)</li>
<p>
結果として、プランナ統計情報の pg_class.reltuples が誤って 0 となる可能性がありました。
</p>
<li>BRINインデックスに挿入される前に、データが確実に TOAST展開されるように、修正されました。  (Tomas Vondra) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
インデックスエントリは 行外の TOASTポインタを含むことができませんが、BRIN では考慮されていませんでした。この結果、「ERROR:  missing chunk number 0 for toast value NNN」といったエラーが発生する可能性がありました。
</p>
<p>
既存のインデックスでこのようなエラーに遭遇した場合には、REINDEX で修正できます。
</p>
<li>INCLUDEカラムを持つインデックスでのバッファ付き GiSTインデックス構築が動作するように修正されました。  (Pavel Borisov) (13)(12)</li>
<p>
CREATE INDEX で格納オプションに buffering=on を指定していたり、インデックスサイズが effective_cache_size 設定値に達した場合に、バッファ付きインデックス構築が行われます。
</p>
<p>
本障害でクラッシュを引き起こす可能性がありました。
</p>
<li>pg_hba_file_rules ビューでの getnameinfo() の移植性のない使用が修正されました。  (Tom Lane) (13)(12)(11)(10)</li>
<p>
FreeBSD 11、そしておそらく他のプラットフォームでは、このエラーのためにビューのアドレスとネットマスクの列が常に null になっていました。
</p>
<li>パラレルワーカの起動時に debug_query_string が NULL の場合のクラッシュが回避されました。  (Noah Misch) (13)(12)(11)</li>
<p>
上記の debug_query_string は PostgreSQL実装内のグローバル変数名です。
</p>
<li>OLD を返す BEFORE ROW UPDATE トリガについて修正されました。  (Amit Langote, Tom Lane) (13)(12)</li>
<p>
OLD を返す BEFORE ROW UPDATEトリガは更新を抑止するために使われます。このようなトリガが、削除されていたり見つからない列を持つテーブルについてOLD を返した場合、これらの列が NULL として読み取られてしまうため、クラッシュ、予期しない CHECK制約の失敗、または正しくない RETURNING の出力が発生する可能性がありました。
</p>
<p>
トリガ作成後に列を削除したり、非NULLのデフォルト値を持つ列を追加したりした場合にこれらの問題が報告されました。
</p>
<li>XML出力モードでの EXPLAIN 出力で、インクリメンタルソートプランのタグが正しく対応するように修正されました。  (Daniel Gustafsson) (13)</li>
<p>
開始タグと終了タグが一致しない不正なXMLが出力されていました。
</p>
<li>PostgreSQLプロトコルにおけるメッセージ送出で、共有メモリキューを介して非常に大きなペイロードを転送する場合の余計なエラーが回避されました。  (Markus Wanner) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
以下のエラーが発生して失敗する可能性がありました。
</p>
<pre>
ERROR:  invalid memory alloc request size .....
</pre>
<p>
修正により、真に失敗する必要がある場合には、メッセージ送出におけるサイズ超過の問題と分かるエラーメッセージが出るようになっています。
</p>
<li>SQL言語で書かれた関数で、いくつかのケースで結果データ型強制の省略が修正されました。  (Tom Lane) (13)</li>
<p>
関わるデータ型によっては、誤った結果やクラッシュにつながる可能性がありました。
</p>
<pre>
（障害動作例: 関数内で型を明示していない場合に戻り値が壊れています）
db1=# CREATE TYPE typ33 AS (a float, b float);
db1=# CREATE FUNCTION f33() RETURNS SETOF typ33 AS $$
        SELECT 1, 2 UNION SELECT 3, 4 ORDER BY 1;
      $$ language sql immutable;

db1=# SELECT f33();
        f33
-------------------
 (5e-324,1e-323)
 (1.5e-323,2e-323)
(2 rows)
</pre>
<li>JITコード生成におけるテンプレート関数属性の不適切な処理が修正されました。  (Andres Freund) (13)(12)(11)</li>
<p>
以前は関数の属性だけをコピーして、パラメータの属性はコピーしていませんでしたが、これが s390x でクラッシュの原因となることが示されており、他のプラットフォームでもその他の問題がある可能性がありました。
</p>
<li>PPC で compare_exchange と fetch_add 操作用に生成されるコードが改善されました。  (Noah Misch) (13)</li>
<li>行レベルセキュリティ(RLS)ポリシーでのリレーションキャッシュのメモリリークが修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<li>index_get_partition() の境界条件的なケースでのメモリリークが修正されました。  (Justin Pryzby) (13)(12)</li>
<li>SIGHUP処理で、再起動をしないと新しいGUC変数の値が適用できないと判断した場合の小さなメモリリークが修正されました。  (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<li>PL/pgSQL の CALL処理でのメモリリークが修正されました。  (Pavel Stehule, Tom Lane) (13)(12)(11)</li>
<li>Windows 版の libpq では、WSAStartup() をプロセスごとに一度だけ呼び出し、WSACleanup() は全く呼び出さないようになりました。  (Tom Lane, Alexander Lakhin) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
以前の libpq は、接続開始時に WSAStartup() を呼び出し、接続のクリーンアップ時に WSACleanup() を呼び出していました。しかし、 WSACleanup() を呼び出すと、他のプログラム操作に干渉する可能性があるようです。特に、期待された出力を標準出力に出力する際にまれに失敗することが観測されています。WSACleanup() の呼び出しを省略しても悪影響はなさそうなので、呼び出さなくなりました。
</p>
<p>
これにより、プログラムが一連のデータベース接続を実行する際にDLL のロードとアンロードが繰り返されることによるパフォーマンスの問題も解消されます。
</p>
<li>Windows用の ecpgライブラリのスレッドごとの初期化ロジックが修正されました。  (Tom Lane, Alexander Lakhin) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
マルチスレッドの ecpg アプリケーションでは、不適切なロックが原因でまれに誤動作が発生する可能性がありました。
</p>
<li>ecpg でのビット文字列 B'...' と X'...' の誤ったリテラル処理が修正されました。  (Shenhao Wang) (13)</li>
<li>Windowsでは、psql が バッククォートコマンドの出力をバイナリモードではなくテキストモードで読み込むようになりました。  (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
これにより、改行を適切に扱えるようになりました。
</p>
<li>pg_dump が拡張の設定テーブルに関する列ごとの情報を確実に収集するようになりました。  (Fabr&iacute;zio de Royes Mello, Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
これに失敗すると --inserts を指定したときにクラッシュしたり、COPY を使用してテーブルのデータを再ロードする際に（通常は正しいのですが）列指定の無い COPYコマンドとなる場合がありました。
</p>
<li>pg_upgrade で対象クラスタ内にテーブル空間のディレクトリが既に存在するかどうかを確認するようになりました。  (Bruce Momjian) (13)(12)(11)(10)(9.6)(9.5)</li>
<li>contrib/pgcrypto の潜在的なメモリリークが修正されました。  (Michael Paquier) (13)(12)(11)(10)(9.6)(9.5)</li>
<li>contrib/pgcrypto に起こりそうもない失敗ケースのチェックが追加されました。  (Daniel Gustafsson) (13)(12)(11)(10)(9.6)(9.5)</li>
<li>アメリカがサマータイムを遵守していない場合にも動作するように、最近追加された timetz のテストケースが修正されました。  (Tom Lane) (13)(12)(11)(10)</li>
<li>タイムゾーンデータファイルが tzdata release 2020d に更新されました。   (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
フィジー、モロッコ、パレスチナ、カナダのユーコン準州、マッコーリー島、南極のケーシー基地の夏時間法の変更に加えて、フランス、ハンガリー、モナコ、パレスチナの歴史的修正が含まれます。
</p>
<li>タイムゾーンライブラリのコピーが IANA tzcode リリース2020d と同期されました。  (Tom Lane) (13)(12)(11)(10)(9.6)(9.5)</li>
<p>
この変更は、アップストリームで zicコマンドのデフォルトの出力オプションがfat から slim へ変更されたことへの対応です。v13 より前のブランチでは引き続き fatモードを選択しているため、これは単なる見た目を整えるための修正です。この変更により、strftime() が失敗しない限り errno が変更されないことも保証されます。
</p>
<li>SLRUログの並列切り捨てによるデータ損失の可能性があり、修正されました。  (Noah Misch) (12)(11)(10)(9.6)(9.5)</li>
<p>
これはごく稀に発生する障害で、後の xid の周回で明らかになるか、または「ERROR:  could not access status of transaction」エラーを引き起こしていました。
</p>
<li>パーティションテーブルに対する ALTER TABLE SET NOT NULL コマンドの実行時、対象となるカラムがすでに NOT NULL としてマークされている場合は、不要な再帰処理を回避するようになりました。  (Tom Lane) (12)</li>
<p>
これにより、並列実行された pg_restore での潜在的なデッドロックが回避されるようになりました。
</p>
<li>継承を使用した CREATE TABLE LIKE の式の処理を修正しました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
CREATE TABLE が LIKE と従来の継承の両方を使用する場合、CHECK制約の列参照と LIKE の親テーブルからの式インデックスに誤った番号が付けられることがよくあり、間違った結果や奇妙なエラーメッセージが出力されていました。 同じことが、その機能を備えたブランチの 生成列(GENERATED) の式でも発生する可能性がありました。
</p>
<p>
本障害の結果、間違った列のマージが行われ、データ挿入時に以下のような列の型が違うというエラーが生じました。CREATE TABLE時のアサート失敗も報告されています。
</p>
<pre>
ERROR:  attribute 1 of type record has wrong type
</pre>
<li>パーティションテーブルに対する DROP INDEX CONCURRENTLY が禁止となりました。  (&Aacute;lvaro Herrera, Michael Paquier) (12)(11)</li>
<p>
この処理は必ず失敗していて、以下のような紛らわしいエラーメッセージが出力されていました。
</p>
<pre>
ERROR:  DROP INDEX CONCURRENTLY must be first action in transaction
</pre>
<p>
エラーメッセージは以下のように変更されました。
</p>
<pre>
ERROR:  cannot drop partitioned index "《インデックス名》" concurrently
</pre>
<li>挿入または更新されたタプルを正しいパーティションにルーティングするときに、デフォルトのパーティション制約を再確認するようになりました。  (Amit Langote, &Aacute;lvaro Herrera) (12)</li>
<p>
これにより、挿入と同時にパーティションが追加された場合に競合が発生する問題が修正されました。
</p>
<li>論理レプリケーションワーカで、不正なキャッシュ無効化ロジックにより発生していた relation 0 キャッシュルックアップ失敗の不具合が修正されました。  (Tom Lane) (12)(11)(10)</li>
<p>
この障害が発生する可能性は低いため、実際の影響は小さく、発生した場合もワーカプロセスが再起動されるだけです。
</p>
<li>論理レプリケーションワーカが冗長な pingリクエストを送信しないようになりました。  (Tom Lane) (12)(11)(10)</li>
<li>スマートシャットダウン中は、すべての（フォアグラウンドの）クライアントセッションが完了するまで、バックグラウンドプロセスを終了しないようになりました。  (Tom Lane) (12)(11)(10)(9.6)</li>
<p>
この変更前は、postmaster が既存の並列ワーカーを終了し、新しい（並列）ワーカーの起動を拒否するため、並列クエリ処理は中断されていました。また、自動バキュームが機能しなくなり、存続しているクライアントセッションが大量のデータ変更を行うと、長期的に深刻な影響を与える可能性がありました。
</p>
<li>postmaster がシグナルを処理している間、スタック領域の再帰的な消費を行わないようになりました。  (Tom Lane) (12)(11)(10)(9.6)</li>
<p>
この変更前には、並列処理を多用すると、並列ワーカープロセスの作成を要求する同時シグナルが多すぎるため、postmaster がクラッシュすることが確認されています。
</p>
<li>SIGQUITシグナルが原因で終了するときは、atexit ハンドラを実行しないようになりました。  (Kyotaro Horiguchi, Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
ほとんどのサーバプロセスはすでにこの慣行に従っていましたが、アーカイバプロセスは見落とされていました。クライアントの起動パケットをまだ待っている状態のバックエンドも、同様にこの慣行に従っていませんでした。
</p>
<li>定数であることが明らかなグループ化列を参照する副問合せ条件に対する誤った最適化が、回避されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
定数サブクエリ出力列は、一部のグループ化セットにのみ表示されるグループ化列である場合、実際には一定ではありませんでした。
</p>
<p>
これにより、グループ化セットを含む問い合わせで誤った結果が返ることがありました。
</p>
<li>SQL関数のインライン化によって、ハッシュ可能なサブプラン比較式の形が変更された場合に失敗しないようになりました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
問い合わせの実行でクラッシュする動作が報告されていました。
</p>
<li>インデックスを構築または再構築している間、同時更新による新しい HOTチェインの発生を許容するようになりました。  (Anastasia Lubennikova, &Aacute;lvaro Herrera) (12)(11)(10)(9.6)(9.5)</li>
<p>
この修正前は、HOT のエラーのために親タプルを見つけられない可能性がありました。その結果、インデックス作成に対して以下のエラーがもたらされました。
</p>
<pre>
ERROR:  failed to find parent tuple for heap-only tuple at (XX,YY) in table "tbl"
</pre>
<li>インデックス条件が満たされないときの並列Bツリーインデックススキャンで、予期せぬエラーや誤った結果が生じることがあり、修正されました。  (James Hunter) (12)(11)(10)</li>
<p>
インデックス列に対する INリストと別の条件とを与える、以下の障害再現手順が確認されています。最後の SELECT結果が変動してしまいます。
</p>
<pre>
db1=# CREATE TABLE t63 AS SELECT generate_series(1,999999) i;
db1=# ALTER TABLE t63 SET (parallel_workers=2, autovacuum_enabled=off);
db1=# CREATE INDEX ON t63 (i);
db1=# SET parallel_leader_participation=off;
db1=# SET min_parallel_table_scan_size=0;
db1=# SET enable_bitmapscan=off;
db1=# SET enable_indexonlyscan=off;
db1=# SET enable_seqscan=off;
db1=# SELECT COUNT(1) FROM t63 WHERE i &gt; 555 AND i IN (
        333,334,335, …中略… ,664,665,666) ORDER BY 1;
</pre>
<li>BRINインデックスのスキャン中に並行して行われるインデックスの要約の解除が正しく行われるようになりました。  (Alexander Lakhin, &Aacute;lvaro Herrera) (12)(11)(10)(9.6)(9.5)</li>
<p>
これまではインデックスのスキャンでインデックス破損と誤認した以下のようなエラーが生じるおそれがありました。
</p>
<pre>
ERROR: corrupted BRIN index: inconsistent range map
</pre>
<li>複数列 GINインデックスのスキャンで「ERROR:  lost saved point in index」が稀に生じることがあり、修正されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
不必要なエラー発生が防止されたのに加えて、メッセージ文面も「ERROR:  failed to re-find tuple within index 《インデックス名》」に変更されました。
</p>
<li>イベントトリガが ALTER TABLE 操作を監視するときに、解放済みメモリ使用の危険性があり、修正されました。  (Jehan-Guillaume de Rorthais) (12)(11)(10)(9.6)(9.5)</li>
<p>これによりクラッシュを引き起こす可能性があります。</p>
<li>一貫性のない移動集約のデータ型に関する誤ったエラーメッセージが修正されました。  (Jeff Janes) (12)(11)(10)(9.6)(9.5)</li>
<p>
CREATE AGGREGATE に指定する関数のデータ型が一致していない場合に以下のようなメッセージが出ますが、そこで示すデータ型が誤っていました。
</p>
<pre>
ERROR:  moving-aggregate implementation returns type 《データ型》, but plain implementation returns type 《データ型》.
</pre>
<li>並列ワーカが非常に長いエラーメッセージを報告するときのハングアップが回避されました。  (Vignesh C) (12)(11)(10)(9.6)(9.5)</li>
<li>libpq が .pgpassファイルの任意の長さの行をサポートするようになりました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
これは主に、非常に長いセキュリティトークンをパスワードとして使用できるようにする場合に役立ちます。
</p>
<li>並列で実行する pg_restore が、パーティションテーブルを参照する外部キーに対して、正しい順序で処理するようになりました。  (&Aacute;lvaro Herrera) (12)</li>
<p>
以前は、必要なインデックスがすべて配置される前に外部キー制約を復元しようとして、エラーが発生する可能性がありました。
</p>
<li>configure のテストプログラムで exit() ではなく return を使用するようになりました。  (Peter Eisentraut) (9.6)(9.5)</li>
<p>
これにより一部の開発環境における configure の失敗を回避しました。
</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>
