<?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.9 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql-11-9/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:31 +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.9 &#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.10 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-10/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Fri, 20 Nov 2020 02:03:34 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.10]]></category>
		<category><![CDATA[PostgreSQL 11.9]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=6595</guid>

					<description><![CDATA[このリリースは 11.9 からの修正リリース（2020年11月12日リリース）です。 11.x からのアップデートではダンプ、リストアは不要です。 ただし、11.6よりも前のバージョンからアップデートする場合には、11. ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 11.9 からの修正リリース（2020年11月12日リリース）です。</p>
<p>11.x からのアップデートではダンプ、リストアは不要です。<br />
ただし、11.6よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/11-6/">11.6 のリリース情報</a>も参照してください。</p>
<p><span id="more-6595"></span></p>
<h3>PostgreSQL 11.9 から 11.10 への変更点</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>
		<item>
		<title>PostgreSQL 11.9 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-9/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Fri, 21 Aug 2020 04:52:48 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.8]]></category>
		<category><![CDATA[PostgreSQL 11.9]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=6285</guid>

					<description><![CDATA[このリリースは 11.8 からの修正リリース（2020年8月13日リリース）です。11.x からのアップデートではダンプ、リストアは不要です。ただし、11.6よりも前のバージョンからアップデートする場合には、11.6 の ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 11.8 からの修正リリース（2020年8月13日リリース）です。11.x からのアップデートではダンプ、リストアは不要です。ただし、11.6よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/11-6/">11.6 のリリース情報</a>も参照してください。</p>
<p><span id="more-6285"></span></p>
<h3>PostgreSQL 11.8 から 11.9 への変更点</h3>
<p>12.4、11.9、10.14、9.6.19、9.5.23 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>論理レプリケーションの walsender と apply worker で、search_path を安全な設定で上書きするようになりました。  (Noah Misch) (12)(11)(10)</li>
<p>
パブリッシャデータベースまたはサブスクライバデータベースの悪意のあるユーザが、レプリケーションを実行するロール（スーパーユーザであることが多い）によって任意のSQLコードの実行を引き起こす可能性がありました。このリスクのいくつかは <a href="https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058%3A_Protect_Your_Search_Path">CVE-2018-1058</a>で説明されているものと同等で、本修正は、レプリケーションの送信者と受信者が空の search_path 設定で実行されるようにして、リスクを緩和します。CVE-2018-1058 の修正と同様に、この変更によりレプリケートされたテーブルの定義で使用されるスキーマ修飾されていないオブジェクト名で問題が生じるかもしれません。
</p>
<p>
信頼されていないロールに属するオブジェクトのレプリケートには他にも危険性があり、そのことについてドキュメント記載されました。(CVE-2020-14349)
</p>
<li>contribモジュールのインストールスクリプトをより安全にしました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
攻撃者が拡張のターゲットスキーマまたは必須とされているスキーマにオブジェクトを作成できる場合、拡張のインストールスクリプトに対して <a href="https://wiki.postgresql.org/wiki/A_Guide_to_CVE-2018-1058%3A_Protect_Your_Search_Path">CVE-2018-1058</a> と同様の攻撃が行われる可能性があります。拡張のインストールにはスーパーユーザ権限を必要とすることが多いため、これによりスーパーユーザ権限を取得するための道が開かれてしまいます。このリスクを軽減するために、スクリプトの実行で使用される search_path により注意を払う、check_function_bodies 設定を無効にしてインストール時のコード実行を回避する、一部の contrib モジュールで使用されているカタログ調整クエリを安全にする、ということが行われました。
</p>
<p>
ドキュメントに、サードパーティの拡張の作者がインストールスクリプトを安全にするための記述が追加されました。これは完全な解決策ではありません。不注意にインストールされた場合、他の拡張に依存する拡張は依然としてリスクがあります。(CVE-2020-14350)
</p>
<li>パーティション除外処理の境界ケースについて修正されました。  (Etsuro Fujita, Dmitry Dolgov) (12)(11)</li>
<p>
パーティションキー列が複数あるとき、一部の列に値を限定する WHERE句が無かったり、限定を与える句が複数あったりする場合に、パーティション除外のための検査の生成が誤動作するおそれがありました。これはサーバプロセスのクラッシュ、不正なクエリ結果、アサート失敗をもたらす可能性がありました。
</p>
<pre>
（クラッシュする例の一つ ／ この場合「b &gt;= 2」が無ければクラッシュしない）
db=# CREATE TABLE pt3 (a int, b int, c int, d int) PARTITION BY RANGE (a, b, c, d);
db=# CREATE TABLE pt3_p1 PARTITION OF pt3 FOR VALUES FROM (1,1,1,0) TO (1,1,1,10);
db=# CREATE TABLE pt3_p2 PARTITION OF pt3 FOR VALUES FROM (2,2,2,0) TO (2,2,2,10);
db=# SELECT * FROM pt3 WHERE a &gt;= 1 AND b &gt;= 1 AND b &gt;= 2 AND c &gt;= 2 AND d &gt;= 0;
server closed the connection unexpectedly
</pre>
<li>パーティション同士の入れ子ループ結合の内部でパラメータ化されたBitmapAnd と BitmapOr のインデックススキャンの構造が修正されました。  (Tom Lane) (12)(11)</li>
<p>
このようなスキャンで結合の外側から値を使用する必要がある実行計画は、通常、実行時にクラッシュします。
</p>
<pre>
（実行するとクラッシュするプラン形状の例 ／ pt4a と pt4b はパーティションテーブル）

db=# EXPLAIN (costs off) SELECT * FROM pt4a WHERE NOT EXISTS (
       SELECT FROM pt4b WHERE pt4b.a = pt4a.a AND pt4b.b = pt4a.b + 1 AND pt4b.c = 123)
       AND a = 1 AND c = 120;
                          QUERY PLAN
---------------------------------------------------------------
 Nested Loop Anti Join
   -&gt;  Seq Scan on pt4a_p1
         Filter: ((a = 1) AND (c = 120))
   -&gt;  Bitmap Heap Scan on pt4b_p1
         Recheck Cond: ((c = 123) AND (b = (pt4a.b + 1)))
         Filter: ((a = 1) AND (a = pt4a_p1.a))
         -&gt;  BitmapAnd
               -&gt;  Bitmap Index Scan on pt4b_p1_c_idx
                     Index Cond: (c = 123)
               -&gt;  Bitmap Index Scan on pt4b_p1_b_idx
                     Index Cond: (b = (pt4b.b + 1))
(11 rows)
</pre>
<li>パーティショニングテーブルが同一の問い合わせで静的パーティショニング除外と実行時パーティショニング除外の両方の対象で、かつ、問い合わせと同時に新しいパーティションが追加された場合に誤った計画が実行されることがあり、修正されました。  (Amit Langote, Tom Lane) (12)</li>
<p>
本障害によりアサート失敗が報告されました。アサートを無効にしている場合、誤った結果やクラッシュがもたらされる可能性があります。また、発生を防ぐ修正に加えて、本ケースはアサートではなく問い合わせのエラーとして報告されるようになりました。
</p>
<li>論理レプリケーションの walsender で、キープアライブメッセージ送信の後にフィードバックメッセージを送信できなかったのが修正されました。  (&Aacute;lvaro Herrera) (12)(11)(10)(9.6)(9.5)</li>
<p>
組み込みの論理レプリケーションを使用している場合は、組み込みの walreceiver が（誤った状態をクリアする）フィードバック返信をいずれにせよかなり頻繁に送信するため、これは比較的小さな問題です。しかし、pglogical のような他のレプリケーションシステムでは、重大な性能問題が発生していました。
</p>
<li>論理レプリケーションのサブスクライバにおける、列指定 UPDATEトリガの起動が修正されました。  (Tom Lane) (12)(11)(10)</li>
<p>
これまでのコードでは、パブリッシャテーブルとサブスクライバテーブルで列番号が異なる可能性を考慮していませんでした。実際に列番号が異なっていた場合、どのトリガを実行するかについて誤った判断をする可能性がありました。
</p>
<li>pg_replication_slot_advance() の実行中に最も古い xmin値とLSN値が更新されるようになりました。  (Michael Paquier) (12)(11)</li>
<p>
pg_replication_slot_advance() 関数は以前これができなかったため、レプリケーションスロットを手動で進めた後にリソースのクリーンアップ（不要になったWALセグメントの削除など）を妨げる可能性がありました。
</p>
<li>ts_headline() の実行遅延が修正されました。  (Tom Lane) (12)(11)(10)(9.6)</li>
<p>
以前の一連のマイナーリリースで追加されたフレーズ検索の修正により、長い文書に対して ts_headline() が不合理に時間を要する可能性がありました。さらに悪いことに時間を要することのあるループ内でキャンセルできませんでした。
</p>
<li>repeat() 関数がクエリキャンセルで確実に中断できるようになりました。  (Joe Conway) (12)(11)(10)(9.6)(9.5)</li>
<li>Windows上での結果にキャリッジリターン("\r")が含まれないようにpg_current_logfile() が修正されました。  (Tom Lane) (12)(11)(10)</li>
<li>pg_read_file() と関連する関数が EOF に達するまで確実に読み込まれるようになりました。  (Joe Conway) (12)(11)</li>
<p>
以前は読み込むデータの長さが指定されていない場合、これらの関数は stat() によって報告されたファイルの長さで停止していました。これはパイプやその他の種類の仮想ファイルには不適切な動作です。
</p>
<li>jsonpath の計算で数値の「NaN」値が禁止されました。  (Alexander Korotkov) (12)</li>
<p>
SQL にも JSON にも 「NaN」(not-a-number) という概念はありませんが、jsonpath のコードはそのような値を許可しようとしていました。これは必然的に非標準の動作につながるため、最初からそのような値を拒否する方が良いと判断されました。
</p>
<li>浮動小数点の集約で、単一の「Inf」または「NaN」の入力が正しく処理されるようになりました。  (Tom Lane) (12)</li>
<p>
影響を受ける集約は以下です。
</p>
<pre>
      corr()
      covar_pop()
      regr_intercept()
      regr_r2()
      regr_slope()
      regr_sxx()
      regr_sxy()
      regr_syy()
      stddev_pop()
      var_pop()
</pre>
<p>
このような場合の集約された値として「NaN」を返すべきですが、PostgreSQL v12 で導入されたアルゴリズム変更のために 0 を返すようになっていました。
</p>
<li>数値型列のパラレル集計時の「NaN」入力の処理が修正されました。  (Tom Lane) (12)(11)(10)(9.6)</li>
<p>
一部の部分集計ワーカーが「NaN」のみを検出し、他のワーカーが「NaN」以外のもののみを検出した場合、結果は誤って結合され全体的に誤った結果（つまり「NaN」であるべき時に「NaN」ではない）になる可能性がありました。
</p>
<li>24時間を超えて表現された時刻を拒否するようになりました。  (Tom Lane) (12)(11)(10)</li>
<p>
日付時刻入力の仕様は、"24:00:00" またはそれに相当する "23:59:60" を許容しますが、それ以上の値は許容しません。しかし、非ゼロの少数秒を伴う "23:59:60.nnn" を受け入れるように範囲チェックが誤って実装されていました。
</p>
<p>
タイムスタンプ値では翌日の1秒目に折り返される結果になりました。time や timetz の値では、保存された値は実際には 24時間より大きくなり、ダンプ/リストアの失敗やその他の誤動作を引き起こす可能性がありました。
</p>
<li>EXPLAIN の非テキスト出力フォーマット（JSON等）において、インデックス名に余計なダブルクォートを付けなくなりました。  (Tom Lane, Euler Taveira) (12)(11)(10)(9.6)(9.5)</li>
<li>Gather Merge を使用している実行計画のパラレルワーカにおいて、EXPLAIN のリソース使用量、特にバッファアクセスに関するリソース使用量の計算が修正されました。  (Jehan-Guillaume de Rorthais) (12)(11)(10)</li>
<li>ALTER TABLE における制約の再検証のタイミングが修正されました。  (David Rowley) (12)(11)(10)(9.6)(9.5)</li>
<p>
ALTER TABLE が（例えば、列のデータ型の変更により）テーブル内容を完全に書き換える必要がある場合で、外部キーや CHECK制約を再検証するためにテーブルをスキャンする必要がある場合に、これらが時々間違った順序で行われ、以下のような奇妙なエラーを引き起こしていました。
</p>
<pre>
 ERROR:  could not read block 0 in file "base/16543/17654": read only 0 of 8192 bytes
</pre>
<li>インデックスのレプリカアイデンティティのフラグを保持するようにREINDEX CONCURRENTLY が修正されました。  (Michael Paquier) (12)</li>
<p>
以前は、テーブルのレプリカID のインデックスをインデックス再構築すると設定が失われ、将来の論理デコード出力に古いタプル値が含まれなくなる原因となっていました。
</p>
<li>pg_subscription.subslotname と pg_subscription_rel.srsublsn の不正確な非NULLの印付けが修正されました。  (Tom Lane) (12)(11)(10)</li>
<p>
初期化時のカタログデータは、これら 2つのカタログ列を常に非NULLであると誤って印付けしていました。その印付けが正しいかどうかに依存している主な場所は、JIT有効時のタプル分解です。本修正では影響が出る箇所でこれらの誤った印付けを無視するようにしています。初期化時のカタログデータはバージョン13以降で修正されます。
</p>
<p>
また、これらの項目の NULL確認を行うコードが追加されました。ただし、NULL確認が無いためにクラッシュする可能性はほとんど無いと考えられます。
</p>
<li>FROM句にある平坦化されていない副問合せに付加された条件句でLATERAL参照が正常に使えるようになりました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
アサート失敗や、クエリ実行時のクラッシュにつながる可能性がありました。
</p>
<pre>
（クラッシュを引き起こす問い合わせ例）
db=# CREATE TABLE t22 (a int);
db=# INSERT INTO t22 VALUES (0), (1), (2);
db=# SELECT * FROM t22, LATERAL (
       SELECT t22.a &gt; 1 AS b, 1 AS c FROM (SELECT random() ORDER BY 1) AS v
       UNION ALL
       SELECT true AS b, 2 AS c
     ) AS vt22 WHERE b AND a &gt;= 0;
server closed the connection unexpectedly
</pre>
<li>選択度推定中に呼び出された演算子にクエリ指定の照合順序を使用するようになりました。  (Tom Lane) (12)</li>
<p>
以前は、データベースの列の照合順序を使用していましたが、正しくクエリの照合順序を使用するようになりました。
</p>
<p>
現在は非決定的な照合順序があるので、修正前は非決定的な照合順序が与えられた場合に演算子が完全に失敗するケースがありました。クエリ自体が動作するようなケースでプラン作成が失敗することは望ましくないため、推定の目的で演算子を呼び出す際には、クエリの照合順序を使用しなければなりませんでした。
</p>
<li>一度も ANALYZE されていない外部テーブルのタプルを 0行と想定しないようになりました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
これは主に、GROUP BY で得られるグループ数のプランナ推定に影響を与えていました。
</p>
<li>BRINインデックスの要約情報の展開で「WARNING:  leftover placeholder tuple detected in BRIN index "..."」という偽りの警告が削除されました。  (&Aacute;lvaro Herrera) (12)(11)(10)</li>
<p>
本ケースはキャンセルされたバキュームの後に合法的に発生する可能性があるので、それに関する警告は過度なものでした。
</p>
<li>共有ファイルセットの一時ファイルが配置されるテーブルスペースの選択が修正されました。  (Magnus Hagander, Tom Lane) (12)(11)</li>
<p>
temp_tablespaces が空か、データベースのテーブルスペースを明示的に指定している場合に、（パラレルハッシュ結合などで用いられる）共有ファイルセットの一時ファイルが期待通りデータベースのテーブルスペースに配置されるのではなく、pg_defaultテーブルスペースに配置されていました。
</p>
<li>WALの整合性をチェックする時の SP-GISTインデックスページのマスキングにおいて稀な場合に発生するエラーが修正されました。  (Alexander Korotkov) (12)(11)</li>
<p>
これにより、wal_consistency_checking設定が有効な場合に偽のエラー報告をする可能性がありました。
</p>
<pre>
（報告されたエラー例）
FATAL:  inconsistent page found, rel 1663/16385/22133, forknum 0, blkno 15
CONTEXT:  WAL redo at 0/739CEDE8 for SPGist/VACUUM_REDIRECT: newest XID 4619
</pre>
<li>サーバの buffileモジュールでのエラー処理が改善されました。  (Thomas Munro) (12)(11)(10)(9.6)(9.5)</li>
<p>
I/O エラーが EOF に到達したことと区別がつかなかったり、全く報告されなかったりするいくつかのケースが修正されました。また、ブロック番号やバイト数などの詳細が追加されました。
</p>
<p>
buffileモジュールは内部的な一時ファイルの読み書きに使われるものです。
</p>
<li>SERIALIZABLE モードでのコンフリクトチェックの異常を修正しました。  (Peter Geoghegan) (12)(11)(10)(9.6)(9.5)</li>
<p>
並行して挿入されたタプルが別の並行トランザクションによって更新され、どちらのタプルのバージョンも現在のトランザクションのスナップショットには見えなかった場合、シリアライズ競合チェックは、タプルが現在のトランザクションの結果に関連しているかどうかについて誤った結論を導き出す可能性がありました。 これにより、直列化失敗でエラーにすべき SERIALIZABLEトランザクションのコミットを許容してしまう可能性がありました。
</p>
<li>デッド状態の btreeインデックスエントリを繰り返しデッド判定しないように修正されました。  (Masahiko Sawada) (12)(11)(10)(9.6)(9.5)</li>
<p>
機能的には無害ですが、チェックサムが有効な場合や wal_log_hints = on の場合、無駄な WAL量増大を引き起こしていました。デッド状態とは無効なエントリであることを示すフラグの付いた状態を意味します。
</p>
<li>fsync が無効の場合に、ファイル同期リクエストを破棄するように、checkpointer プロセスが修正されました。  (Heikki Linnakangas) (12)</li>
<p>
そのようなリクエストは fsync が無効の場合には無視されますが、保留中の処理を保持するハッシュテーブルから削除する対応が漏れていました。この問題によりハッシュテーブルが肥大化し、再度 fsync を有効化した場合に、アサート失敗が発生する可能性がありました。
</p>
<li>バックアップ中に JITコンパイルを動作させたときに、非排他的ベースバックアップのクリーンアップ処理中に問題が生じることがあり、回避されました。  (Robert Haas) (12)(11)</li>
<p>
偽性の警告「WARNING:  aborting backup due to backend exiting beforepg_stop_backup was called」や、アサート失敗が報告されました。
</p>
<li>pg_control の変更前に正しいロックを取得するように、一部のコードパスの問題が修正されました。  (Nathan Bossart, Fujii Masao) (12)(11)(10)(9.6)(9.5)</li>
<p>
この問題により、一貫性のないチェックサムで pg_control が書き込まれる可能性があり、次に書き込む前にクラッシュした場合、データベースを再起動できないなど、あとで問題が発生する可能性がありました。
</p>
<li>関数 currtid() および currtid2() のエラーが修正されました。  (Michael Paquier) (12)(11)(10)(9.6)(9.5)</li>
<p>
これらの関数（文書化されておらず、ODBC ドライバの古いバージョンのみで使用）には、クラッシュを発生させたり、パーティションテーブルなど、ストレージのないテーブルに対して呼び出すと、「could not open file」などの混乱を招くエラーメッセージを表示する問題が含まれていました。
</p>
<li>スピンロックの取得中に elog() または palloc() を呼び出さないように修正されました。  (Michael Paquier, Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
レプリケーションスロット関連の処理の一部では、このコーディング規則に違反していました。そのため、関数の呼び出し中にエラーが発生すると、ごくまれにスピンロックがスタックする可能性がありました。
</p>
<li>論理レプリケーションのサブスクライバで「REPLICA IDENTITY FULL」が使用できるように、アサートが修正されました。  (Euler Taveira) (12)(11)(10)</li>
<p>
この問題は、アサートが誤っていただけで、通常の製品ビルドには影響ありません。
</p>
<li>libpq が書き込みに失敗した後もデータベース接続ソケットから読み込みを試し続けるようになりました。  (Tom Lane) (12)</li>
<p>
この修正は、停止しかけのサーバプロセスから最後のエラーメッセージを確実に取得するためだけでなく、読み取りエラーが発生するまで接続が失われたことを考慮せず済ますためにも重要です。これまで、COPY データの転送中に接続が失なわれた場合に、アプリケーションにエラーを報告することなく、永遠に送信し続ける可能性がありました。
</p>
<li>libpq で GSS暗号化状態の管理についてバグが修正されました。  (Tom Lane) (12)</li>
<p>
GSS暗号化を使用した接続では、サーバの再起動後にリセットしようとしたとき、または候補サーバのリストの次に移動しようとしたとき、フリーズしてしまう可能性がありました。
</p>
<li>bytea およびカーソル変数による ecpgコマンドのクラッシュが修正されました。  (Jehan-Guillaume de Rorthais) (12)</li>
<li>pg_dump および pg_basebackup でディスク容量不足エラーが正しく報告されるようになりました。  (Justin Pryzby, Tom Lane, &Aacute;lvaro Herrera) (12)(11)(10)(9.6)(9.5)</li>
<p>
一部のコードパスでは「could not write file: Success」などのおかしな報告が生成される可能性がありました。
</p>
<li>pg_restore で、データオフセットなしのカスタム形式のダンプファイルでも、順不同のデータ項目をリストアできるように改善されました。  (David Gilman, Tom Lane) (12)</li>
<p>
pg_dump では、出力をシークできない（例えば、出力が何かにパイプされている）場合に、そのようなダンプファイルを生成します。この修正により、そのようなダンプファイルでも並列リストアができるようになります。
</p>
<li>テーブル単位と列単位のアクセス権限を両方とも設定したテーブルを並列リストアする場合の問題が修正されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
アクセス権限はテーブル単位を先に付与する必要がありますが、並列リストアではそれを確実に順序づけできていませんでした。この問題により、「tuple concurrently updated」のエラーが発生したり、列単位のアクセス権限が付与されない可能性がありました。この問題はアクセス権限間の依存関係をダンプファイルに含めることで修正しています。そのため、問題が再発しないようにするには、修正された pg_dump でダンプを取得しなおす必要があります。
</p>
<li>pg_upgrade の実行時に対象クラスタで vacuum_defer_cleanup_age が 0 に設定されるようになりました。  (Bruce Momjian) (12)(11)(10)(9.6)(9.5)</li>
<p>
これまで、対象クラスタで vacuum_defer_cleanup_age が 0 以外に設定されている場合、システムカタログの凍結処理が正しく動作せず、混乱を招くメッセージとともにアップグレードが失敗していました。アップグレード中は設定が上書きされることに注意してください。
</p>
<li>pg_recvlogical で終了前に保留中のメッセージを送信するように修正されました。  (Noah Misch) (12)(11)(10)(9.6)(9.5)</li>
<p>
この修正がないと、レプリケーションの senderプロセスが送信障害を検出した場合に、レプリケーションスロットの LSN 位置に対して予期した最後の更新をせずに終了する可能性があります。この問題により、再接続時にデータが再送信されたり、pg_recvlogical が受信しようとした最後のデータの後に送信されたエラーメッセージを見逃す可能性がありました。
</p>
<li>pg_rewind でソースクラスタ内の削除されたばかりのファイルの処理が修正されました。  (Justin Pryzby, Michael Paquier) (12)(11)(10)(9.6)(9.5)</li>
<p>
オンラインのソースクラスタを使用する場合、ファイルを同時に削除できますが、これまで、ファイルのディレクトリエントリを確認してから、stat() でそれを調査するまでの間に削除されると、pg_rewind の動作に混乱が生じていました。
</p>
<li>Windows で pg_test_fsync がバイナリ I/O モードを使用するようになりました。  (Michael Paquier) (12)(11)(10)(9.6)(9.5)</li>
<p>
これまで、テキストモードでテストファイルに書き込んでいましたが、これはPostgreSQL での実際の使用方法を正しく反映したものではありませんでした。
</p>
<li>contrib/amcheck で空の削除済みインデックスページに対してエラーが発生しないように修正されました。  (Alexander Korotkov) (12)(11)</li>
<p>
この状態は WAL の再生中は正常です。
</p>
<li>contrib/dblink でローカル状態を正しく初期化できない問題が修正されました。  (Joe Conway) (12)(11)(10)(9.6)(9.5)</li>
<p>
状況の組み合わせによっては、この問題は dblink_close() が予期しないリモート COMMIT を発行する可能性がありました。
</p>
<li>contrib/pgcrypto で deflate() の誤った使用方法が修正されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
これまで、pgp_sym_encrypt 関数では、zlib の API 要件を正しく処理していなかったため、誤った圧縮データを生成する可能性がありました。標準的なzlib でこのエラーが発生したとの報告はありませんが、IBM の zlibNX 実装を使用した場合に問題が確認されました。
</p>
<li>contrib/pgcrypto の pgp_sym_decrypt 関数でごく稀に発生する解凍処理の問題が修正されました。  (Kyotaro Horiguchi, Michael Paquier) (12)(11)(10)(9.6)(9.5)</li>
<p>
圧縮されたストリームは空のパケットで正常に終了する可能性がありますが、解凍処理はこれに対応しておらず、データが破損しているとのエラーが発生していました。
</p>
<li>Microsoft Visual Studio 2015 以降で NLSコードのビルドに対応しました。  (Juan Jos&eacute; Santamar&iacute;a Flecha, Davinder Singh, Amit Kapila) (12)(11)(10)(9.6)(9.5)</li>
<li>ソースツリー上に configure という名前のファイルが複数ある場合に、MSVC インストールスクリプトが失敗する問題が修正されました。  (Arnold M&uuml;ller) (12)(11)(10)(9.6)(9.5)</li>
<p>
この問題により、ソースツリーのトップレベルを識別するために、configureを検索する処理に混乱が発生していました。
</p>
<li>BSD系の sys_siglist[] の代わりに POSIX 標準の strsignal() を使用するようになりました。  (Tom Lane) (11)(10)(9.6)(9.5)</li>
<p>
この修正により、最新バージョンの glibc でもビルドエラーが発生しなくなります。
</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>
