<?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>PostgreSQL12.5 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql12-5/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, 30 Oct 2026 08:20:47 +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>PostgreSQL12.5 &#8211; SRA OSS Tech Blog</title>
	<link>https://www.sraoss.co.jp/tech-blog/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>PostgreSQL 12.6 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/12-6/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Tue, 02 Mar 2021 08:42:16 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 12]]></category>
		<category><![CDATA[PostgreSQL 12.6]]></category>
		<category><![CDATA[PostgreSQL12.5]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=6761</guid>

					<description><![CDATA[このリリースは 12.5 からの修正リリース（2021年2月11日リリース）です。 12.X からのアップデートではダンプ、リストアは不要です。 しかしながら、１番、３番、４番の項目にはバージョンアップ後に実施すべき手順 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 12.5 からの修正リリース（2021年2月11日リリース）です。<br />
12.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、１番、３番、４番の項目にはバージョンアップ後に実施すべき手順があります。</p>
<p><span id="more-6761"></span>また、12.2より前のバージョンからアップデートする場合には<a href="/tech-blog/pgsql/12-2/">12.2のリリース情報</a>も参照してください。</p>
<h3>PostgreSQL 12.5 から 12.6 への変更点</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>
	</channel>
</rss>
