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

<channel>
	<title>PostgreSQL 11.11 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql-11-11/feed/index.xml" rel="self" type="application/rss+xml" />
	<link>https://www.sraoss.co.jp/tech-blog/</link>
	<description>OSS専門の技術ブログ。PostgreSQL、Zabbixを中心に10種類以上のOSSの解説、アップデート情報、運用ヒントを提供。</description>
	<lastBuildDate>Thu, 22 Oct 2026 07:46:07 +0000</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1.3</generator>

<image>
	<url>https://www.sraoss.co.jp/tech-blog/wp-content/uploads/2018/07/blog-icon-150x150.png</url>
	<title>PostgreSQL 11.11 &#8211; SRA OSS Tech Blog</title>
	<link>https://www.sraoss.co.jp/tech-blog/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>PostgreSQL 11.12 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-12/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Tue, 25 May 2021 01:56:13 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.11]]></category>
		<category><![CDATA[PostgreSQL 11.12]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=6998</guid>

					<description><![CDATA[このリリースは 11.11 からの修正リリース（2021年5月13日リリース）です。 11.X からのアップデートではダンプ、リストアは不要です。 しかしながら、11.11 よりも前のバージョンから移行する場合には 11 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 11.11 からの修正リリース（2021年5月13日リリース）です。<br />
11.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、11.11 よりも前のバージョンから移行する場合には <a href="/tech-blog/pgsql/11-11">11.11 のリリース情報</a>も確認してください。</p>
<p><span id="more-6998"></span></p>
<h3>PostgreSQL 11.11 から 11.12 への変更点</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 11.11 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-11/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Tue, 02 Mar 2021 08:40:14 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.10]]></category>
		<category><![CDATA[PostgreSQL 11.11]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=6759</guid>

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