<?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 12.5 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql-12-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>Wed, 04 Nov 2026 06:36:29 +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 12.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.5 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/12-5/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Fri, 20 Nov 2020 02:04:49 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 12]]></category>
		<category><![CDATA[PostgreSQL 12.4]]></category>
		<category><![CDATA[PostgreSQL 12.5]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=6593</guid>

					<description><![CDATA[このリリースは 12.4 からの修正リリース（2020年11月12日リリース）です。 12.x からのアップデートではダンプ、リストアは不要です。 ただし、12.2よりも前のバージョンからアップデートする場合には、12. ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 12.4 からの修正リリース（2020年11月12日リリース）です。</p>
<p>12.x からのアップデートではダンプ、リストアは不要です。<br />
ただし、12.2よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/12-2/">12.2 のリリース情報</a>も参照してください。</p>
<p><span id="more-6593"></span></p>
<h3>PostgreSQL 12.4 から 12.5 への変更点</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>
