<?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 9.6 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql-9-6/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>Mon, 09 Nov 2026 03:38:44 +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 9.6 &#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 9.6.24 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-6-24/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Thu, 21 Apr 2022 02:50:33 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.6]]></category>
		<category><![CDATA[PostgreSQL 9.6.23]]></category>
		<category><![CDATA[PostgreSQL 9.6.24]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=9786</guid>

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

<div>
<a href="https://www.sraoss.co.jp/prod_serv/support/pgsql-mainte/?utm_source=sraoss-techblog&utm_medium=referral&utm_campaign=under-article-pgsql" rel="noopener" style="color:initial;" target="_blank" class="no-ext"></p>
<div style="background-color:#DAEFF6; padding:20px; border-radius:8px; text-align:center;">
SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。<br />
詳しくは<strong style="color:#2581c4;">弊社ホームページ</strong>をご覧ください。
</div>
<p></a>
</div>

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 9.6.23 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-6-23/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Wed, 01 Sep 2021 01:58:29 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.6]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=7235</guid>

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

<div>
<a href="https://www.sraoss.co.jp/prod_serv/support/pgsql-mainte/?utm_source=sraoss-techblog&utm_medium=referral&utm_campaign=under-article-pgsql" rel="noopener" style="color:initial;" target="_blank" class="no-ext"></p>
<div style="background-color:#DAEFF6; padding:20px; border-radius:8px; text-align:center;">
SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。<br />
詳しくは<strong style="color:#2581c4;">弊社ホームページ</strong>をご覧ください。
</div>
<p></a>
</div>

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 9.6.22 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-6-22/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Tue, 25 May 2021 01:53:01 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.6]]></category>
		<category><![CDATA[PostgreSQL 9.6.21]]></category>
		<category><![CDATA[PostgreSQL 9.6.22]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=7002</guid>

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

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

<div></div>
<div>
<a href="https://www.sraoss.co.jp/prod_serv/support/pgsql-mainte/?utm_source=sraoss-techblog&utm_medium=referral&utm_campaign=under-article-pgsql" rel="noopener" style="color:initial;" target="_blank" class="no-ext"></p>
<div style="background-color:#DAEFF6; padding:20px; border-radius:8px; text-align:center;">
SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。<br />
詳しくは<strong style="color:#2581c4;">弊社ホームページ</strong>をご覧ください。
</div>
<p></a>
</div>

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 9.6.20 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-6-20/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Fri, 20 Nov 2020 02:01:49 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.6]]></category>
		<category><![CDATA[PostgreSQL 9.6.19]]></category>
		<category><![CDATA[PostgreSQL 9.6.20]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=6599</guid>

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

					<description><![CDATA[このリリースは 9.6.18 からの修正リリース（2020年8月13日リリース）です。9.6.x からのアップデートではダンプ、リストアは不要です。ただし、9.6.16よりも前のバージョンからアップデートする場合には、9 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.6.18 からの修正リリース（2020年8月13日リリース）です。9.6.x からのアップデートではダンプ、リストアは不要です。ただし、9.6.16よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/9-6-16/">9.6.16 のリリース情報</a>も参照してください。</p>
<p><span id="more-6289"></span></p>
<h3>PostgreSQL 9.6.18 から 9.6.19 への変更点</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>
		<item>
		<title>PostgreSQL 9.6.18 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-6-18/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Wed, 20 May 2020 02:11:09 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.6]]></category>
		<category><![CDATA[PostgreSQL 9.6.17]]></category>
		<category><![CDATA[PostgreSQL 9.6.18]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=5926</guid>

					<description><![CDATA[このリリースは 9.6.17 からの修正リリース（2020年5月14日リリース）です。9.6.x からのアップデートではダンプ、リストアは不要です。ただし、9.6.16よりも前のバージョンからアップデートする場合には、9 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.6.17 からの修正リリース（2020年5月14日リリース）です。9.6.x からのアップデートではダンプ、リストアは不要です。ただし、9.6.16よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/9-6-16/">9.6.16 のリリース情報</a>を参照してください。</p>
<p><span id="more-5926"></span></p>
<h3>PostgreSQL 9.6.17 から 9.6.18 への変更点</h3>
<p>12.3、11.8、10.13、9.6.18、9.5.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<ol>
<li>生成列（GENERATED 指定された列）で起こりうるクラッシュが修正されました。  (David Rowley) (12)</li>
<p>
生成列が、テーブル内の他の列の単なるコピーで、かつ、リファレンス渡しのデータ型（文字列型など）である場合、テーブルに壊れたデータが投入されるかクラッシュを引き起こす可能性がありました。他の列を単に複製する GENERATED式という役に立たない使い方に限られればよいですが、時に入力そのものを返す関数を使っている式で本状況が生じる可能性があります。
</p>
<p>
本障害で以下のようなデータ投入時に巨大なメモリ要求によるエラーが出るケースも報告されました。
</p>
<pre>
ERROR:  XX000: invalid memory alloc request size 18446744073709551613
</pre>
<li>生成列の継承の扱いが改善されました。  (Peter Eisentraut) (12)</li>
<p>
CREATE TABLE ... INHERITS でテーブルの列が継承された場合、親の列が生成列（GENERATED）であるときに子の列で生成列であるという属性を変更することが禁止され、一方で、親の列が生成列でないときに子の列で GENERATED を指定して生成列にできるようになりました。
</p>
<p>
これらの規則が不明瞭であったことに起因して、生成列と継承の組み合わせを含むテーブル定義のダンプがリストアできない場合が報告されました。
</p>
<li>CREATE TABLE ... LIKE ... INCLUDING GENERATED で、列をまたがる参照が修正されました。  (Peter Eisentraut) (12)</li>
<p>
物理的に後ろにある列を参照する GENERATED式をコピーしようとするときに CREATE TABLE ... LIKE が以下のようなエラーを起こしました。
</p>
<pre>
（報告されたエラー発生例）
db=# CREATE TABLE t3 (
     funds float GENERATED ALWAYS AS (cast(funds_t AS double precision)) STORED,
     funds_t text,
     id bigserial not null);

db=# CREATE TABLE IF NOT EXISTS t3_temp (LIKE t3 INCLUDING GENERATED);
ERROR:  XX000: unexpected varattno 3 in expression to be mapped
</pre>
<li>ALTER TABLE ... SET STORAGE がインデックスに伝搬するようになりました。  (Peter Eisentraut) (12)(11)</li>
<p>
式でないインデックス列は作成時には常に、そのテーブル列の attstorage属性をコピーしていました。整合性を維持するように、ALTER TABLE ... SET STORAGE ... が実行されたときにインデックスに対しても属性を変更するようになりました。
</p>
<li>ALTER TABLE で書き換えられたインデックスの indisclustered属性を維持するようになりました。  (Amit Langote, Justin Pryzby) (12)(11)(10)(9.6)(9.5)</li>
<p>
indisclustered は pg_indexシステムテーブルの列で、前回テーブルを当該インデックスを使って CLUSTERコマンドを実行した場合にtrue となります。これまで、当該列を対象に ALTER TABLE を実行すると、この情報が失われていました。
</p>
<li>ALTER TABLE で書き換えられたインデックスの REPLICA IDENTITY属性が維持されるようになりました。  (Quan Zongliang, Peter Eisentraut) (12)(11)(10)(9.6)(9.5)</li>
<p>
REPLICA IDENTITY属性は、論理レプリケーション用に使われ、ALTER TABLE ... REPLICA IDENTITY USING INDEX ... コマンドで指定されます。pg_indexシステムテーブルの列名としては indisreplident です。これまで、当該列を対象に ALTER TABLE を実行すると、この情報が失われていました。
</p>
<li>REINDEX CONCURRENTLY で再構築されたインデックスの indisclustered属性が維持されるようになりました。  (Justin Pryzby) (12)</li>
<p>
これまで、このような場合に属性が失われ、REINDEX CONCURRENTLY後のCLUSTERコマンド実行が失敗する可能性がありました。
</p>
<li>DROP OWNED BY コマンドにおいて、オブジェクトをより早くロックするようになりました。  (&Aacute;lvaro Herrera) (12)(11)(10)(9.6)(9.5)</li>
<p>
これにより、他セッションがいくつかの同オブジェクトを削除している場合の競合状態によるエラーを回避します。以下のエラーが出るケースが報告されました。
</p>
<pre>
ERROR:  cache lookup failed for relation 41019
</pre>
<li>CREATE ROLE ... IN ROLE ... のエラー処理が修正されました。  (Andrew Gierth) (12)(11)(10)(9.6)(9.5)</li>
<p>
一部のエラーケースでは意図通りのメッセージの代わりに「unexpected node type」といったエラーメッセージが報告されていました。
</p>
<li>パーティションがデタッチされたときに、旧親テーブルから複製されたトリガが確実に除去されるように修正されました。  (Justin Pryzby) (12)(11)</li>
<p>
これまで、パーティションをデタッチした際にトリガが残ってしまう動作があり、そのようなトリガは、旧親テーブルとの依存関係のために以下のようなエラーが出て、削除不能となっていました。
</p>
<pre>
db=# ALTER TABLE t10p DETACH PARTITION t10c;
db=# DROP TRIGGER trig ON t10c;
ERROR:  cannot drop trigger trig on table t10c because trigger trig on table t10p requires it
</pre>
<li>パーティション境界の式で、COLLATE が照合不可能な型に適用されるとクラッシュする不具合があり、修正されました。  (Dmitry Dolgov) (12)</li>
<pre>
（該当する例: 整数型に COLLATE を指定する式を与えている）
db=# CREATE TABLE t11p (i int) PARTITION BY LIST (i);
db=# CREATE TABLE t11c1 PARTITION OF t11p FOR VALUES IN ('1' COLLATE "POSIX");
</pre>
<li>パーティショニングされたテーブル上のユニークインデックスが、パーティショニングキーの等価性セマンティクスと一致するかどうかを確認するようになりました。  (Guancheng Luo) (12)(11)</li>
<p>
これは独自の等価性演算子を持つインデックス演算子クラスだけの問題ですが、理論的には間違っていたので、確認するように修正されました。
</p>
<li>pg_read_all_statsロールのメンバが、期待通りにすべての統計情報ビューを参照できるようになりました。  (Magnus Hagander) (12)(11)(10)</li>
<p>
pg_read_all_statsロールのメンバ は pg_stat_progress_* ビューを参照できるとドキュメントに記載されていましたが、実際には参照できませんでした。
</p>
<li>information_schema.triggersビューのパフォーマンス劣化が修正されました。  (Tom Lane) (12)(11)</li>
<p>
この修正は、テーブル名を制約する外側の WHERE句がプッシュダウンされるようにビューを再定義し、計算がデータベース内の全トリガではなく、対象テーブルに属するトリガに対してのみ行われるようにします。多くのトリガを持つデータベースでは、この変更でかなりの速度差が出ます。
</p>
<p>
バージョン11より前には修正後と同様に動作していたので、これは潜在的なパフォーマンス劣化でした。
</p>
<p>
本修正は既存のデータベースクラスタには適用されませんが、明示的にビュー定義を置き換えることで修正することができます。information_schema.triggersビューを含む情報スキーマの定義はソースコードの以下パスにあります。
</p>
<pre>
src/backend/catalog/information_schema.sql
</pre>
<li>浮動小数点オーバーフローおよびアンダーフロー検出のパフォーマンス低下が修正されました。  (Emre Hasegeli) (12)</li>
<p>
以前のリファクタリングで、いくつかのホットなコードパスで isinf() を余分に呼び出すようになっていました。
</p>
<li>全文検索がフレーズ検索上の NOT を正しく処理できるように修正されました。  (Tom Lane) (12)(11)(10)(9.6)</li>
<p>
これまで、GiST や GIN インデックス検索として実行されている場合、「!(foo &lt;-&gt; bar)」のようなクエリで、マッチする行が見つからない問題が発生していました。
</p>
<li>全文検索のフレーズ検索で、前方一致と重み限定の両方を持つ項目が含まれる場合に、マッチ漏れが発生する不具合が修正されました。  (Tom Lane) (12)(11)(10)(9.6)</li>
<p>
以下のような場合が該当します。
</p>
<pre>
（マッチすべきところでマッチしない障害動作例）
db=# SELECT 'wa:1D wb:2A'::tsvector @@ 'w:*D &lt;-&gt; w:*A'::tsquery as "true";
 true
------
 f
(1 行)
</pre>
<li>フレーズ検索を使うときにより良い見出しが選択されるように、ts_headline() 関数が修正されました。  (Tom Lane) (12)(11)(10)(9.6)</li>
<p>
検索条件部分が適切に強調されない動作が報告されました。
</p>
<li>gin_fuzzy_search_limit の処理の不具合が修正されました。  (Ad&eacute; Heyward, Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
gin_fuzzy_search_limit の値が小さいと、意図せずに同じインデックスページを何度も再スキャンしてしまい、予期せず遅くなる可能性がありました。別のコードパスでは、意図したフィルタリングの適用に失敗しており、多すぎる値を返す可能性がありました。
</p>
<li>ドキュメント通りに circle型の入力として「(x,y),r」形式を受け付けるようになりました。  (David Zhang) (12)(11)(10)(9.6)(9.5)</li>
<pre>
（修正前のエラー発生例）
db=# SELECT '( 1 , 1 ) , 5'::circle;
ERROR:  invalid input syntax for type circle: "( 1 , 1 ) , 5"
</pre>
<li>get_bit() と set_bit() 関数が 256MB より長い bytea文字列に対応しました。  (Movead Li) (12)(11)(10)(9.6)(9.5)</li>
<p>
ビット数の引数が int4 のみなので、これらの関数を使用して長い bytea の最初の256MB を超えるビットにアクセスすることはできません。バージョン 13 では引数が int8 に拡張される予定ですが、それまでの間は、これらの関数が長い bytea の最初の部分文字列で動作します。
</p>
<p>
修正前は、このような場合に以下エラーが発生していました。
</p>
<pre>
ERROR:  index 0 out of valid range, 0..-1
</pre>
<li>pg_ls_waldir() とその関連関数で、ファイルが見つからないというエラーを無視するようになりました。  (Tom Lane) (12)(11)(10)</li>
<p>
これは、ディレクトリエントリが参照されてからstat() を実行しようとするまでの間にファイルが削除された場合の競合状態による失敗を防ぎます。
</p>
<li>pg_ls_dir()、pg_timezone_names()、pg_tablespace_databases()、および、関連関数で、ディレクトリの開いたファイルディスクリプタがリークする可能性があり、回避されました。  (Justin Pryzby) (12)(11)(10)(9.6)(9.5)</li>
<li>多様関数の型解決が修正されました。anyrange の入力のみを与えられた場合に、anyarray の出力が実際の型を正しく推論するようになりました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
そのような場合に以下のエラーが出るケースが報告されました。
</p>
<pre>
db=# CREATE FUNCTION f24(x anyrange, out lu anyarray, out ul anyarray)
     LANGUAGE SQL
     AS 'SELECT array[lower(x),upper(x)], array[upper(x),lower(x)]';

db=# SELECT * FROM foo24(int4range(6,9));
ERROR:  cache lookup failed for type 0
</pre>
<li>GSSAPI対応でコンパイルされていないために GSSAPI接続が拒否され、クライアントが代わりに SSL 接続を試みる場合の、サーバの接続開始ロジックが修正されました。  (Andrew Gierth) (12)</li>
<p>
これまで、以下の FATALメッセージで失敗していました。
</p>
<pre>
FATAL:  unsupported frontend protocol 1234.5679: server supports 2.0 to 3.0
</pre>
<li>GSSAPI暗号化でのメモリリークが修正されました。  (Tom Lane) (12)</li>
<p>
これまで、GSSAPI暗号化が使用されている場合、バックエンドと libpq の両方がセッション中に送信されたデータの総量に相当するメモリリークが発生していました。
</p>
<li>クエリの FROM句で使用される集合を返す関数のメモリリークが修正されました。  (Andres Freund) (12)</li>
<p>
これにより以下のような問い合わせのメモリ使用量が巨大になっていました。
</p>
<pre>
db=# SELECT sum(f) FROM generate_series(1, 1000000) g(i),
                        generate_series(i, i+1) f;
</pre>
<li>複数回使われるハッシュ化されたサブプランのハッシュテーブルのリークが回避されました。  (Andreas Karlsson, Tom Lane) (12)(11)</li>
<p>
この誤りは、ハッシュ化されたサブプランのクエリを十分な回数再実行した時に、深刻なメモリの肥大化を引き起こす可能性がありました。
</p>
<li>プランナによる何もしないドメインに型変換する処理が改善されました。  (Tom Lane) (12)</li>
<p>
何もしないドメインへの型変換が式から完全に取り除かれない場合があり、修正されました。旧メジャーバージョンと比べて動作が遅くなっていたことが報告されていました。
</p>
<li>REINDEX が SIGTERM（セッションシャットダウン）シグナルで終了した時のクラッシュが回避されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>実際には上記の状況であっても本障害でのクラッシュ発生は稀です。</p>
<li>EXPLAIN でおそらく不正とみられるハッシュ結合テーブルの統計情報が出力されていたものが、防止されました。  (Konstantin Knizhnik, Tom Lane, Thomas Munro) (12)(11)(10)(9.6)(9.5)</li>
<p>
以下のような EXPLAIN出力（一部抜粋）が報告されていました。
</p>
<pre>
-&gt;  Hash  (cost=0.11..0.11 rows=10 width=12) (actual time=0.002..0.002 rows=1 loops=8)
      Buckets: 2139062143  Batches: 2139062143  Memory Usage: 8971876904722400kB
      -&gt;  Function Scan on unnest init_1  (cost=0.01..0.11 rows=10 width=12) (actual time=0.001..0.001 rows=1 loops=8)
</pre>
<li>VACUUM VERBOSE でのヒープ切り捨て段階の経過時間の報告が修正されました。  (Tatsuhito Kasahara) (12)(11)(10)(9.6)(9.5)</li>
<p>
これまで不正確な経過時間が報告されていました。
</p>
<li>VACUUM VERBOSE の出力で、削除された B-treeインデックスについてページ数が過小に報告されていたものが、修正されました。  (Peter Geoghegan) (12)(11)</li>
<li>B-treeインデックスで最も古い削除されたページに対する誤った記録付けが修正されました。  (Peter Geoghegan) (12)(11)</li>
<p>
これによって、VACUUM がインデックスのクリーンアップスキャンをスキップできる場合について、微妙に間違った判断をする可能性がありました。
</p>
<li>TimelineHistoryRead と TimelineHistoryWrite の待機状態が、.historyファイルを読み書きするすべてのコードパスで報告されるようになりました。  (Masahiro Ikeda) (12)(11)(10)</li>
<li>プロセスの PS状態で「waiting」が重複して表示されないように修正されました。  (Masahiko Sawada) (12)(11)(10)(9.6)(9.5)</li>
<pre>
（誤った psコマンドの出力行の例）
46510   ??  Ss     0:00.05 postgres: startup   recovering 000000010000000000000003 waiting waiting
</pre>
<li>拡張統計データのカタログタプルを ANALYZE で置き換えた場合の競合状態が回避されました。  (Dean Rasheed) (12)</li>
<p>
VACUUM FULL などの操作が同時に行われた場合に、ANALYZE が間違ったタプルを置換してしまう可能性がありました。
</p>
<li>「冗長な」周回防止バキュームの不用意なスキップが回避されました。  (Michael Paquier) (12)</li>
<p>
これにより、自動バキュームが何度もトライしては同じバキュームジョブをスキップすることを繰り返すというまれなケースが回避されます。
</p>
<li>B-tree のピボットタプルから INCLUDEされたカラムが常に削除されるようになりました。  (Peter Geoghegan) (12)</li>
<p>
この誤りはまれにスペースを無駄にしましたが、それ以外は無害です。
</p>
<li>REINDEX CONCURRENTLY に失敗した後に残る可能性のある無効な TOASTインデックスを適切に扱うようになりました。  (Julien Rouhaud) (12)</li>
<p>
REINDEX CONCURRENTLY に失敗した後に REINDEX TABLE を行った場合に、使用できず、削除もできない重複したインデックスが作成されてしまう問題が生じていました。
</p>
<li>REINDEX CONCURRENTLY が失敗した後でも、有効なインデックスの依存関係が維持されるように対応されました。  (Michael Paquier) (12)</li>
<p>
以前は pg_depend のリンクがまったくない古いインデックスを残すことがありえたため、例えば親テーブルが削除されてもインデックスは削除されずに残ってしまいました。
</p>
<li>autovacuum がドロップされたばかりの一時スキーマにアクセスしようとした場合にクラッシュする障害が回避されました。  (Tom Lane) (12)(11)</li>
<p>
この障害はスーパーユーザが一時スキーマを手動で削除した場合にのみ発生します。これは一般的な状況ではありませんが、この場合も動作すべきでした。
</p>
<li>クラッシュリカバリ中の WALセグメントの早すぎるリサイクルが回避されました。  (Jehan-Guillaume de Rorthais) (12)(11)(10)(9.6)(9.5)</li>
<p>
クラッシュリカバリの間にアーカイブされる準備が整った WALセグメントがアーカイブされずにリサイクルされる可能性がありました。
</p>
<li>アーカイブリカバリ中に無関係なタイムラインがスキャンされないようになりました。  (Kyotaro Horiguchi) (12)(11)(10)(9.6)(9.5)</li>
<p>
これにより、アーカイブストレージから存在しない WAL ファイルをフェッチしようとする多くの試みを排除することが可能となり、アーカイブへのアクセスが遅い場合に役立ちます。
</p>
<li>論理デコーディングでの「subtransaction logged without previous top-level txn record」 というエラーの検査が削除されました。  (Arseny Sher, Amit Kapila) (12)(11)(10)(9.6)(9.5)</li>
<p>
この条件は様々なシナリオで正当に到達可能なため取り除かれました。
</p>
<li>レプリケーションスロットのコピー後に障害が発生する可能性があり、回避されました。  (Masahiko Sawada, Arseny Sher) (12)</li>
<p>
WALデータが適切に取りおかれず、早くに削除されてしまう可能性がありました。
</p>
<li>レプリケーションスロットの「io_in_progress_lock」がエラー時のコードパスで確実に解放されるようになりました。  (Pavan Deolasee) (12)(11)(10)(9.6)(9.5)</li>
<p>
本障害のため walsender が後でロックを待機したまま動けなくなる可能性がありました。
</p>
<li>論理レプリケーションによって発行された更新のときに、生成列が正しく確実に処理されるようになりました。  (Peter Eisentraut) (12)</li>
<p> これまで、このような場合に生成列が更新されませんでした。
</p>
<li>同期スタンバイ管理での競合状態が修正されました。  (Tom Lane) (12)(11)(10)(9.6)</li>
<p>
synchronous_standby_names の設定を変更している間、同期コミットを待っているトランザクションをリリースしてもよいかどうかについて、誤った判断を下す可能性がありました。 また、walsenderプロセスが終了してすぐにプロセスが再起動された場合にも、同様に誤った判断を下す危険性がありました。
</p>
<li>いくつかのエラー報告に欠落していた SQLSTATE値が追加されました。  (Sawada Masahiko) (12)(11)(10)(9.6)(9.5)</li>
<li>イベントトリガ関数の通常関数としての実行を確実に拒否するようにPL/pgSQL が修正されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
そのような関数実行でクラッシュが発生していました。
</p>
<li>「sslmode=verify-full」を使用した時の libpq でのメモリリークが修正されました。  (Roman Peshkurov) (12)(11)(10)(9.6)(9.5)</li>
<p>
接続開始時の証明書の検証は、いくらかのメモリリークの可能性があり、クライアントプロセスの起動中にデータベース接続を多数オープンした場合に問題となる可能性がありました。
</p>
<li>すべてのプラットフォームで「-」引数を「標準入力からの読み込み」を意味するものとして扱うように ecpg が修正されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
AIX で動作しないケースが報告されていました。
</p>
<li>psql で失敗した接続を復旧しようとした時に発生するクラッシュが修正されました。  (Michael Paquier) (12)</li>
<li>psql の \gx コマンドが引数（ファイル名）のタブ補完できるようになりました。  (Vik Fearing) (12)(11)(10)</li>
<p>
\gx コマンドは直前の SQL 実行結果を拡張出力モードで引数に指定したファイルへ書き込みます。
</p>
<li>pg_dump で ALTER ... DEPENDS ON EXTENSION がサポートされました。  (&Aacute;lvaro Herrera) (12)(11)(10)(9.6)</li>
<p>
以前の pg_dump はこの依存関係を無視してしまい、ダンプ/リストアや pg_upgrade時にそれらが反映されませんでした。
</p>
<li>pg_dump が RLSポリシーオブジェクトのコメントをダンプするように修正されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<li>pg_dump がイベントトリガのリストアを最後に行なうようになりました。  (Fabr&iacute;zio de Royes Mello, Hamid Akhtar, Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
これにより、イベントトリガが他のオブジェクトの復元に干渉するリスクを最小限に抑えることができます。
</p>
<li>pg_basebackup が有効な tarファイルを確実に生成するようになりました。  (Robert Haas) (12)</li>
<p>
ファイルの末尾にゼロ埋めされたブロックが追加されることがありました。これは一般的なバージョンの tar では問題ないようですが、POSIXファイル形式の仕様としては問題がありました。
</p>
<li>pg_checksums および pg_verify_checksums がメジャーバージョンの異なるテーブル空間のサブディレクトリをスキップするようになりました。  (Michael Banck, Bernd Helmle) (12) (11)</li>
<p>
このようなサブディレクトリは実際にはデータベースクラスタには属していないので、処理してはいけませんでした。
</p>
<li>pg_checksums および pg_verify_checksums と関連プログラムで、pg_internal.init の一時的なコピーを無視するようになりました。  (Michael Paquier) (12) (11)</li>
<li>createdb の --encoding、--lc-ctype、--lc-collate の値のクォート処理が修正されました。  (Michael Paquier) (12)(11)(10)(9.6)(9.5)</li>
<p>
以下の通り、正しくクォートされた文字列を認識できるようになりました。
</p>
<pre>
（PostgreSQL 12.2 の createdb コマンド）
$ createdb --lc-collate "foo'; SELECT '1" 'foobar2'
createdb: error: database creation failed: ERROR:  CREATE DATABASE cannot run inside a transaction block

（PostgreSQL 12.3 の createdb コマンド）
$ createdb --lc-collate "foo'; SELECT '1" 'foobar2'
createdb: error: database creation failed: ERROR:  invalid locale name: "foo'; SELECT '1"
</pre>
<li>contrib/lo の lo_manage()関数が、トリガとしてではなく直接呼ばれた場合でもクラッシュしなくなりました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<li>contrib/ltree で、ltree と lquery のフィールド長がオーバーフローしないようになりました。  (Nikita Glukhov) (12)(11)(10)(9.6)(9.5)</li>
<p>
これまではフィールド長が 65535 を超えると 0 になっていましたが、本修正によって ERROR が返るようになりました。
</p>
<pre>
（修正前の動作）
db=# SELECT nlevel(('1' || repeat('.1', 65534))::ltree);
 nlevel
--------
  65535
(1 row)

db=# SELECT nlevel(('1' || repeat('.1', 65535))::ltree);
 nlevel
--------
      0
(1 row)


（修正後の動作）
db=# SELECT nlevel(('1' || repeat('.1', 65535))::ltree);
ERROR:  number of ltree levels (65536) exceeds the maximum allowed (65535)
</pre>
<li>oldest_xact値が 2^31-1 を超えても contrib/pageinspect の bt_metap() 関数が失敗しなくなりました。  (Peter Geoghegan) (12)(11)</li>
<p>
このような XID は負の整数として報告されるようになりました。これはワークアラウンドですが、エラーを投げるよりは良いと判断されました。これまで、以下のようなエラーが発生していました。
</p>
<pre>
db=# SELECT * FROM bt_metap('index');
ERROR: value "2180413846" is out of range for type integer
</pre>
<li>contrib/sepgsql で誤った「WARNING: cache reference leak」メッセージが出力されなくなりました。  (Michael Luo) (12)(11)(10)(9.6)(9.5)</li>
<li>Windows で pg_ctl start 時の早すぎるログファイル作成を回避するようになりました。  (Alexander Lakhin) (12)</li>
<p>
Windows の pg_ctl で、-l で指定したログファイルがまだ存在せず、pg_ctl が Administrator権限で実行されている場合、postmaster から書き込みできないパーミッションでログファイルが作成されて、権限不足のエラーが生じる可能性がありました。
</p>
<li>Windows で Unixスタイルのロケール名を扱う際に失敗しないようになりました。  (Juan Jos&eacute; Santamar&iacute;a Flecha) (12)(11)(10)(9.6)(9.5)</li>
<p>
Unixスタイルのロケール文字列（たとえば "et_EE.UTF-8"）の場合、ドットの後にあるのはエンコーディング名です。これを Windows のコードページ番号として扱って、以下のエラーが生じていました。
</p>
<pre>
&gt; initdb.exe --locale et_EE.UTF-8 -D C:\data
initdb: ERROR:  invalid locale name "et_EE.UTF-8"
</pre>
<p>
そのため、ドットの後の文字がすべて数字であるかどうかを確認し、そうでない場合はコードページ番号ではなくエンコーディング名として扱うようになりました。
</p>
<li>Windows で、PG_COLOR のカラー化をサポートするプログラムでコンソールの VT100 互換モードを設定するようになりました。  (Juan Jos&eacute; Santamar&iacute;a Flecha) (12)</li>
<p>
これを設定していないと、カラー化オプションが実際には動作しませんでした。
</p>
<li>ereport() の呼び出しで余分な括弧が要求されなくなりました。  (Andres Freund, Tom Lane) (12)</li>
<p>
これはソースコード内のインターフェースに関連する修正です。
</p>
<li>configure で libxml2 の位置を確認するために、利用可能な場合は pkg-config を使用するようになりました。  (Hugh McMaster, Tom Lane, Peter Eisentraut) (12)(11)(10)</li>
<p>
pkg-config が存在しないか、libxml2 に関する情報がない場合は、これまで通りxml2-config に問い合わせます。
</p>
<p>
この変更により、PostgreSQL がデフォルトではないバージョンの libxml2 を使用する場合、そのバージョンの xml2-config を PATH に設定すると、ビルドプロセスが中断される可能性があります。代わりに、XML2_CONFIG にデフォルトではない xml2-config を設定してください。この方法は、古いバージョンの PostgreSQL でも新しいバージョンの PostgreSQL でも動作します。
</p>
<li>libpq と ecpg の、Makefile の依存関係を修正しました。  (Dagfinn Ilmari Mannsaker) (12)</li>
<li>MSVCビルドで Python のパス名のスペースに対処するようになりました。  (Victor Wagner) (12)(11)(10)(9.6)(9.5)</li>
<li>Visual Studio のバージョン検出が修正され、MSVC ビルドがより多くの言語設定で動作するようになりました。  (Andrew Dunstan) (12)(11)(10)(9.6)(9.5)</li>
<li>Windows 以外のビルドではすでにそうなっているように、MSVC ビルドでも、3.0 より新しいバージョンの bison では "-Wno-deprecated" を使用するようになりました。  (Andrew Dunstan) (12)(11)(10)(9.6)(9.5)</li>
<li>タイムゾーンデータファイルが tzdata release 2020a に更新されました。モロッコとカナダのユーコンの DST法の変更と上海の歴史的な修正が含まれます。   (12)(11)(10)(9.6)(9.5)</li>
<p>
America/Godthabゾーンは、現在の英語の使用法を反映するために America/Nuuk に名称変更されました。変更前の名前も互換性のために利用可能なままです。
</p>
<p>
また、initdb の既知の Windowsタイムゾーン名のリストが最近追加されたものを含むように更新され、そのプラットフォーム上のシステムのタイムゾーン設定が正しく翻訳される可能性が高まりました。
</p>
<li>パーティショニングされたテーブルで、制約違反エラーが発生した後に低頻度で発生するクラッシュが修正されました。  (Andres Freund) (11)(10)</li>
<li>nextXid がスタンバイサーバ上で後戻りしないようになりました。  (Eka Palamadai) (11)(10)(9.6)(9.5)</li>
<p>
この競合状態により、誤ったホットスタンバイフィードバックメッセージがプライマリサーバに送り返される可能性があり、VACUUM がプライマリ上ですぐに実行されてしまう可能性がありました。
</p>
<li>共有ライブラリのビルドする時に CXXFLAGS に CFLAGS_SL を含めるようになりました。  (Oleksii Kliukin) (10)</li>
<p>
これにより、必要に応じて "-fPIC" を追加するなど、C++ のソースファイルが正しくコンパイルされるようになります。11.x以降バージョンでは既にそのようになっています。
</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 9.6.17 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-6-17/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Fri, 28 Feb 2020 05:02:57 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.6]]></category>
		<category><![CDATA[PostgreSQL 9.6.16]]></category>
		<category><![CDATA[PostgreSQL 9.6.17]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=5725</guid>

					<description><![CDATA[このリリースは 9.6.16 からの修正リリース（2020年2月13日リリース）です。9.6.x からのアップデートではダンプ、リストアは不要です。9.6.16 より前のバージョンからのアップデートの場合には、9.6.1 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.6.16 からの修正リリース（2020年2月13日リリース）です。9.6.x からのアップデートではダンプ、リストアは不要です。9.6.16 より前のバージョンからのアップデートの場合には、<a href="/tech-blog/pgsql/9-6-16/">9.6.16 のリリース情報</a>も参照してください。</p>
<p><span id="more-5725"></span></p>
<h3>PostgreSQL 9.6.16 から 9.6.17 への変更点</h3>
<p>12.2、11.7、10.12、9.6.17、9.5.21、9.4.26 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<hr />
<ol>
<li>欠けていた ALTER ... DEPENDS ON EXTENSION 文の権限検査が追加されました。(CVE-2020-1720)  (&Aacute;lvaro Herrera) (12)(11)(10)(9.6)</li>
<p>
関数、プロシージャ、トリガ、マテリアライズドビュー、インデックスに対する本SQL文について修正が行われました。本SQL文はデータベースオブジェクトが拡張に依存していると印付けするものです。依存関係があると、拡張を DROPする際にそのデータベースオブジェクトも削除されます。
</p>
<p>
本SQLの実行際して何ら権限チェックが行われていませんでした。そのため、拡張を削除できるユーザは権限の無いオブジェクトを削除可能でした。また、管理者が拡張を削除する際に権限の無いオブジェクトを削除させるように仕組むことができました。
</p>
<p>
本SQLの実行には対象オブジェクトの所有者であることが要求されるように修正されました。
</p>
<li>TRUNCATE ... CASCADE が関連する全てのパーティションを確実に空にするように修正されました。  (Jehan-Guillaume de Rorthais) (12)</li>
<p>
パーティションテーブルのパーティションが CASCADEオプション付きでTRUNCATEされた場合で、かつ、パーティションテーブルが他テーブルからの外部キー参照を持っていた場合、参照しているテーブルも空にされるべきです（通常のテーブルもそのように動作します）。参照しているテーブルがパーティションテーブルである場合に検査に取りこぼしがあり、外部キー制約違反の行が残る可能性がありました。
</p>
<p>
このため、データベースにパーティションテーブル間の外部キー制約があり、これまでに被参照テーブルにパーティション単位で TRUNCATE を行っていたなら、外部キー違反が無いかを確認することを推奨します。
</p>
<p>
最も簡単な確認方法は新たに同定義の外部キー制約を加えることです（確認用なので追加に成功したら、削除します）。ロック取得の観点から、これが実施しにくい場合には、SELECT文で制約違反の行を探してください。
</p>
<li>外部キー制約が追加した副パーティションに付加されない障害が修正されました。  (Jehan-Guillaume de Rorthais) (12)</li>
<p>
複数階層パーティションテーブルの第二階層以下にパーティションをアタッチするとき、そのパーティションテーブルを参照する外部キー制約が新たなパーティションに複製されず、その結果、後で制約違反を引き起こす可能性がありました。
</p>
<p>
簡単な修復方法は、そのパーティションをデタッチしてアタッチすることです。修復すべきパーティションが大量にある場合には、新たに同定義の外部キー制約を追加する方法が良いでしょう。
</p>
<li>パーティションテーブルまたは継承ツリーで同時更新中にクラッシュが生じる可能性があり、修正されました。  (Tom Lane) (12)</li>
<li>パーティションテーブルの行トリガが適時に正しく副パーティションに複製されるように修正されました。  (&Aacute;lvaro Herrera) (12)(11)</li>
<p>
（外部キー制約やユニーク制約のトリガではなく）ユーザ定義トリガについて、パーティションの作成やアタッチをするときに取りこぼしが生じるおそれがありました。
</p>
<li>ロジカルレプリケーションのサブスクライバ側のコードが、適時に列ごとの UPDATEトリガを実行するように修正されました。  (Peter Eisentraut) (12)(11)(10)</li>
<p>
このようなトリガが実行されないことがありました。
</p>
<li>大きいトランザクションを多数の分割された一時ファイルに書き出ししなければならないときの、ロジカルデコーディングでのエラーが回避されました。  (Amit Khandekar) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
ファイル識別子を使いすぎて、以下のようなエラーが出るケースが報告されていました。
</p>
<pre>
ERROR:  exceeded maxAllocatedDescs (492) while trying to open file "pg_replslot/logical/xid-2362-lsn-0-24000000.spill"
</pre>
<li>ロジカルレプリケーションのサブスクライバが行更新を処理するときに、クラッシュやデータ破損の可能性があり、修正されました。  (Tom Lane, Tomas Vondra) (12)(11)(10)</li>
<p>
本障害は、サブスクライバのテーブルがパブリッシャからコピーされていないリファレンス渡しのデータ型の列を含む場合に限って、顕在化した問題を発生させます。
</p>
<p>
text や numeric など格納サイズが大きいデータ型はリファレンス渡しです。ビルドオプションによっては int8 や float8 もリファレンス渡しになります。
</p>
<li>ロジカルレプリケーションのサブスクライバのクラッシュが修正されました。サブスクライブしているテーブルで DDL変更（ALTER TABLE）をした後にクラッシュが発生しました。  (Jehan-Guillaume de Rorthais, Vignesh C) (12)(11)(10)</li>
<li>ロジカルレプリケーションのパブリッシャにおける、データベースがクラッシュ終了して再起動した後に起きるアサートエラーが修正されました。  (Vignesh C) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<li>物理レプリケーションスロットにおいて pg_replication_slot_advance() の効果が再起動後も維持されるようになりました。  (Alexey Kondratov, Michael Paquier) (12)(11)</li>
<li>REPLICA IDENTITY FULL を用いたロジカルレプリケーションの効率が改善されました。  (Konstantin Knizhnik) (12)(11)(10)</li>
<p>
更新や削除の操作に際して、既存タプルを探すときに最初に一致したタプルを返すようになりました。これまでは全てを調べる動作になっていました。
</p>
<li>ベースバックアップが INT32_MAX より大きいデータベースの OID を扱えるように修正されました。  (Peter Eisentraut) (12)</li>
<p>
大きい OID値を持つデータベースがあるときに、以下のようなエラーが報告されていました。
</p>
<pre>
pg_basebackup: error: could not get write-ahead log end position from server: ERROR:  value "3000000000" is out of range for type integer
</pre>
<li>常に適切なタイミングでパラレルプランノードが終了(shutdown)されるようになりました。   (Kyotaro Horiguchi) (12)(11)</li>
<p>
この障害は、複数バッチの（即ち、件数が多くてメモリに載らない場合の）パラレルハッシュ結合の際に、以下のような予期せぬ警告を発生させました。
</p>
<pre>
WARNING:  temporary file leak: File 15 still referenced
</pre>
<li>Limitノードの下の Gather または GatherMerge プランノードの早すぎる終了(shutdown) が防止されました。  (Amit Kapila) (12)(11)(10)(9.6)</li>
<p>
これにより、入れ子ループの内側にある等、このようなプランノードを複数回スキャンする必要がある場合の障害を回避します。本障害でクラッシュする動作が報告されました。
</p>
<li>多コアCPU でのパラレルハッシュ結合の効率が改善されました。  (Gang Deng, Thomas Munro) (12)(11)</li>
<p>
無駄な処理を削って、それによる CPUキャッシュ間の同期処理の発生を回避します。
</p>
<li>パラレル CREATE INDEX での動的共有メモリスロットの空きが無いときのクラッシュが回避されました。  (Thomas Munro) (12)(11)</li>
<p>
そのような場合には非パラレルのインデックス作成が行われるようになります。
</p>
<li>動的共有メモリスロットが無いときのメモリリークが修正されました。  (Thomas Munro) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
以下のエラーが発生する場合にリークが発生しました。
</p>
<pre>
ERROR: too many dynamic shared memory segments
</pre>
<li>一時テーブルに対するインデックス作成、削除、再構築時にCONCURRENTLYオプションを無視するようになりました。  (Michael Paquier, Heikki Linnakangas, Andres Freund) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
これにより一時テーブルが ON COMMITアクションを持っていた場合の奇妙なエラーを回避します。以下のような発生ケースが報告されました。
</p>
<pre>
=# CREATE TEMP TABLE t0(c1 INT PRIMARY KEY) ON COMMIT DELETE ROWS;
=# REINDEX TABLE CONCURRENTLY t0;
ERROR:  index "t0_pkey_ccnew" already contains data
</pre>
<p>
他のセッションは一時テーブルにアクセスできないため、一時テーブルに対するインデックス作成で CONCURRENTLY を使う利点はありません。
</p>
<li>ON COMMIT DELETE ROWS を伴う一時テーブルに対する式インデックスをコミット時にリセットするときに起こりうる誤動作が修正されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<li>box型、範囲型、inet型に対する BRINインデックスの操作でクラッシュの可能性があり、修正されました。  (Heikki Linnakangas) (12)(11)(10)(9.6)(9.5)</li>
<li>GiSTインデックス作成での再帰的なページ分割中に起きるクラッシュが修正されました。  (Heikki Linnakangas) (12)</li>
<li>GINインデックスで削除済みページの処理が修正されました。  (Alexander Korotkov) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
本障害ではデッドロックや、削除済みページの誤った状態更新、最近に削除されたページを辿る動作の失敗、を起こす可能性があり、これらが回避されました。
</p>
<li>複数行の VALUESリスト内の SubPlan（副SELECT）でクラッシュの可能性があり、修正されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
一例として、以下のような形状の問い合わせが該当します。
</p>
<pre>
SELECT * FROM (
 SELECT * FROM (
  VALUES ('A'::text NOT IN (
   SELECT 'E'::text AS col_1 FROM (
    VALUES (NULL), (NULL), (NULL), (NULL)) AS tab_1 (col_2)
     WHERE false),
   NULL, 'B'::text, 3::int),
  (false, 4::int, 'B'::text, 0::int)) AS tab_3 (col_4, col_5, col_6, col_7)
 WHERE tab_3.col_4) AS tab_8 ORDER BY 1, 2, 3, 4;
</pre>
<li>ALTER TABLE で、GENERATED句の式で参照されている列が、同じ ALTER文中の手前で追加されたり型変更されている場合のエラーが修正されました。  (Tom Lane) (12)</li>
<p>
例えば以下のような操作でエラーが発生していました。
</p>
<pre>
db=# CREATE TABLE t25 (a int, b int, c int, x int);
db=# INSERT INTO t25 VALUES (1, 1, 1, 1), (2, 2, 2, 2);
db=# ALTER TABLE t25
       DROP COLUMN x,
       ALTER COLUMN a TYPE bigint,
       ALTER COLUMN b TYPE bigint,
       ADD COLUMN x bigint GENERATED ALWAYS AS ((a + b) * 2) STORED;
ERROR:  attribute 1 of type t25 has wrong type
DETAIL:  Table has type integer, but query expects bigint.
</pre>
<li>タプル変換時に、失った属性に対するデフォルト値の挿入に失敗していたものが修正されました。  (Vik Fearing, Andrew Gierth) (12)(11)</li>
<p>
この障害で、定数デフォルトを伴う ALTER TABLE .. ADD COLUMN で追加された列の値が誤って NULL と読み取られる可能性がありました。
</p>
<p>
タプル変換とは行データをレコード型に代入するときなどに必要となる内部処理です。
</p>
<li>チェックポイント処理にて、削除されているかもしれないリレーションのセグメントを開くことで、稀に PANIC になる可能性があり、修正されました。  (Thomas Munro) (12)</li>
<li>FileClose() 失敗後におきるクラッシュが修正されました。  (Noah Misch) (12)(11)(10)</li>
<p>
この問題は data_sync_retry = on の場合のみ該当します。off の場合には FileClose() 失敗は（仕様通りに）PANIC になるはずです。
</p>
<li>外部テーブルに対する複数の AFTER ROW トリガの処理が修正されました。  (Etsuro Fujita) (12)</li>
<p>
トリガを駆動されたときにアサートエラーが生じる動作が報告されました。
</p>
<li>リファレンス渡しのデータ型の集約関数の遷移状態でクラッシュの可能性があり、修正されました。  (Andres Freund, Teodor Sigaev) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
PL/pgSQL関数を使ってユーザ定義した集約関数を実行したときにアサートエラーが生じるケースが報告されました。
</p>
<li>to_date() と to_timestamp() のエラー報告が改善されました。  (Tom Lane, &Aacute;lvaro Herrera) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
入力文字列中の誤った月や曜日に関するエラー報告が、誤った部分を示すときマルチバイト文字の途中で切り出すことがあり、続くエラーの元になる不適切なエンコードのエラーメッセージをもたらしました。
</p>
<p>
これを回避するため、次の空白文字までを切り出し範囲とするようになりました。
</p>
<li>紀元前の日付に対する EXTRACT(ISOYEAR FROM timestamp) に一年ずれた結果を返す誤動作があり、修正されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<pre>
（障害動作例: B.C. 7年について -7 を返すのが正しい動作）
db=# SELECT EXTRACT(ISOYEAR FROM 'Feb 03 04:05:06 0007 PST BC'::timestamp);
 date_part
-----------
        -6
(1 row)
</pre>
<li>char型に対する &lt;&gt; 演算子があいまいな照合順序のエラーを適切に報告するようになりました。  (Tom Lane) (12)</li>
<p>
以下のように、どの照合順序を使って処理すべきか判別できない場合に、予期せぬエラーメッセージや、アサートエラーが出ていました。
</p>
<pre>
db=# CREATE TABLE t33 (c0 char(2) COLLATE "C", c1 char(2) COLLATE "POSIX");
db=# INSERT INTO t33 VALUES ('', '');

db=# SELECT * FROM t33 WHERE c1 &lt;&gt; c0;
ERROR:  cache lookup failed for collation 0
（予期せぬエラー出力）

db=# SELECT * FROM t33 WHERE c1 = c0;
ERROR:  could not determine which collation to use for string comparison
HINT:  Use the COLLATE clause to set the collation explicitly.
（こちらは望ましいエラー出力）
</pre>
<li>TIDスキャンがシーケンシャルスキャンとして処理されないように修正されました。  (Tatsuhito Kasahara) (12)</li>
<p>
リファクタリングの誤りで、TIDスキャン（ctid列による選択）が実行時統計情報ビューでシーケンシャルスキャンとして数えられており、さらに、シーケンシャルスキャンのようにテーブル全体の術部ロックを取りました。後者の動作は SERIALIZABLE トランザクションモードで不要な直列化失敗エラーを引き起こす可能性がありました。
</p>
<li>システムカタログに自己参照ビューがあるときの information_schemaビューでのスタックオーバフローが回避されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
リレーションが更新可能かを調べる内部実装関数が、自己参照ビューに対して無限再帰を起こすため、そのような場合に処理を打ち切るように修正されました。
</p>
<li>walsenderプロセスが pg_stat_activity のトランザクション開始時刻に常に NULL を見せるようになりました。  (&Aacute;lvaro Herrera) (12)(11)(10)</li>
<p>
これまでは xact_start 列にプロセス開始時刻があらわれることがありました。
</p>
<li>ハッシュ結合で、内側リレーションが巨大な場合の性能が改善されました。  (Thomas Munro) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<li>多数の稼働中 walsenderプロセスがあるときの、スピンロック競合が軽減されました。  (Pierre Ducroquet) (12)</li>
<li>EXPLAIN の出力で "Subplans Removed" フィールドの配置が修正されました。  (Daniel Gustafsson, Tom Lane) (12)(11)</li>
<p>
テキスト以外の出力形式では、このフィールドは Plans 副グループの内側に出力されて、構文的に不正な出力になっていました。
</p>
<p>
JSON形式であれば以下のような形の不正な出力があり得ました。
</p>
<pre>
    "Plans": [
        { ..サブプラン.. },
        "Subplans Removed": 5,
        { ..サブプラン.. }
    ]
</pre>
<p>
"Subplans Removed" は親の Append や MergeAppend プランノードに付けるように修正されました。
</p>
<p>
この変更はテキスト形式にも反映されます。これまで InitPlan の下にあった Subplans Removed は、InitPlan よりも手前に現れるようになります。
</p>
<li>EXPLAIN の SETTINGS オプションが非テキストの出力フォーマットで空で出力されるように修正されました。  (Tom Lane) (12)</li>
<p>
非テキストの出力フォーマットでは、たとえ値が空やゼロであっても、各フィールドが存在することが期待されます。
</p>
<li>ユーザが問い合わせに明示的に現れるテーブルの対応する列を読める場合には、プランナが潜在的に漏洩のあるテストを子テーブル（パーティション）の統計情報に適用できるようにしました。  (Dilip Kumar, Amit Langote) (12)(11)</li>
<p>
この変更は、CVE-2017-7484 セキュリティ障害の修正で生じた、パーティションテーブルの性能問題を修正します。先のセキュリティ修正では、現在ユーザが直接には読むことのが許可されない列の統計情報に、漏洩のある演算子を適用できないようにしました。
</p>
<p>
一方で、親のパーティションテーブルのみに参照権限があって、個々のパーティションには権限が無いというのは、ごく一般的な状態です。ユーザは親のパーティションテーブルを通して、子パーティションの列を参照できます。このような場合に、先のセキュリティ修正のためにプランナの見積もりが必要以上に劣化していました。
</p>
<li>単一行副問い合わせの結合に対する積極的すぎる組み換えによって引き起こされるプランナのエラーが修正されました。  (Tom Lane) (12)</li>
<p>
この誤りは、以下のような予期せぬエラーをもたらしました。また、アサートエラーになる可能性もありました。
</p>
<pre>
（本エラーを発生させる問い合わせ例）
db=# SELECT FROM (
      SELECT FROM pg_stat_bgwriter AS r0
       LEFT JOIN pg_stat_bgwriter AS r1 ON (true), LATERAL (
        SELECT FROM pg_publication AS r2, LATERAL (
         SELECT FROM pg_class WHERE r1.buffers_alloc IS NOT NULL
         ) AS sq0 LIMIT 1) AS sq1) AS sq2;
ERROR:  failed to construct the join relation
</pre>
<li>「no = operator for opfamily NNNN」というプランナのエラーが修正されました。  (Tom Lane) (12)</li>
<p>
LIKE や正規表現のパターンマッチ演算子をバイナリ互換のインデックス演算子クラスでマッチさせようとするときに発生しました。
</p>
<pre>
（発生例: text型とバイナリ互換の char型に対応した bpchar_ops を使用しています）
db=# CREATE TABLE t43 (c text);
db=# CREATE INDEX i43 ON t43 (c bpchar_ops);
db=# SELECT * FROM t43 WHERE t43.c LIKE '';
ERROR:  no = operator for opfamily 426
</pre>
<li>範囲型に対する &lt;@ および @&gt; 演算子に対する選択度の計算で、境界ケースでのクラッシュ、または、誤った見積もりが、修正されました。  (Michael Paquier, Andrey Borodin, Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
列のプランナ統計情報と比較条件の値とが特定条件に合致する場合に問題が発生します。
</p>
<li>MVC（最頻値）の拡張統計情報を使っているときの、OR句に対するプランナの不正確な見積もりが修正されました。  (Tomas Vondra) (12)</li>
<p>
拡張統計情報が a と b の間に作られているところで、以下のような問い合わせを実行するとき、アサートエラーが出る動作が報告されました。アサート無効のときにはプランナの見積もりが不正確になります。
</p>
<pre>
SELECT * FROM t45 WHERE (a = 1) OR (b = 1) OR (c = 1)
</pre>
<li>MCV（最頻値）拡張統計情報を適用するときに、システム列を無視するようになりました。  (Tomas Vondra) (12)(11)(10)</li>
<p>
これにより以下のように、システム列を参照する問い合わせで予期せぬエラーが発生するのを防止します。
</p>
<pre>
db=# CREATE TABLE t46 (id int, c1 int, c2 int);
db=# INSERT INTO t46 SELECT g, g, g FROM generate_series(1, 1000) as g;
db=# CREATE STATISTICS s46 ON id, c1 FROM t46 ;
db=# ANALYZE t46;
db=# SELECT (ctid::text::point)[0] blkno, count(*) cn FROM t46
       GROUP BY blkno ORDER BY cn DESC LIMIT 10;
ERROR:  negative bitmapset member not allowed
</pre>
<li>BRINインデックスのロジックが、仮定の BRINインデックスに対応するように修正されました。  (Julien Rouhaud, Heikki Linnakangas) (12)(11)(10)</li>
<p>
これまでは、何らかインデックスアドバイザ拡張が仮定の BRINインデックスを伴うプランを生成させようとすると、BRINコスト見積もりコードが常にインデックスのメタページに物理的にアクセスしようするため、失敗しました。
</p>
<li>条件付き INSTEADルールを伴うビューの自動更新を使おうとするときのエラー報告が改善されました。  (Dean Rasheed) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
これはサポートされていないものですが、これまでは、そのことを示すエラーがエグゼキュータによる実行時にしか出ませんでした。そのため、不明瞭なプランナのエラーで原因が隠されてしまうおそれがありました。
</p>
<p>
リライタの段階で以下のようなエラーメッセージが出るようになりました。
</p>
<pre>
db=# CREATE TABLE t48 (a int PRIMARY KEY, b text);
db=# INSERT INTO t48 VALUES (2, '2');
db=# CREATE VIEW v48 AS SELECT a, b, a AS aa FROM t48;
db=# CREATE RULE v48_upd_rule AS ON UPDATE TO v48
       WHERE OLD.a &gt; 0 DO INSTEAD UPDATE t48 SET b=NEW.b WHERE a=OLD.a;
db=# UPDATE v48 SET b = 'ROW 2' WHERE a = 2;
ERROR:  cannot update view "v48"
DETAIL:  Views with conditional DO INSTEAD rules are not automatically updatable.
HINT:  To enable updating the view, provide an INSTEAD OF UPDATE trigger or an unconditional ON UPDATE DO INSTEAD rule.

（以下は修正前バージョン 12.1 でのエラーメッセージ）
ERROR:  no relation entry for relid 2
</pre>
<li>複合型が範囲型を通して間接的に自身に含まれることを防止しました。  (Tom Lane, Julien Rouhaud) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
元々自分自身を含む複合型は作成できない仕様でした。本修正で以下の操作がエラーになります。
</p>
<pre>
db=# CREATE TYPE two_ints AS (a int, b int);
db=# CREATE TYPE two_ints_range AS RANGE (subtype = two_ints);
db=# ALTER TYPE two_ints ADD ATTRIBUTE c two_ints_range;
ERROR:  composite type two_ints cannot be made a member of itself drop type two_ints cascade;
NOTICE:  drop cascades to type two_ints_range
（上記は修正後の動作、修正前はエラーにならない）
</pre>
<li>record のような疑似データ型を返すパーティションキーの式が禁止されました。  (Tom Lane) (12)(11)(10)</li>
<p>
そのようなパーティションテーブルに対する問い合わせで、何らかエラーやスタックオーバーフロー（ERROR:  stack depth limit exceeded）が起きる動作が報告されました。定義時点でエラーが出るようになります。
</p>
<li>インデックスを作成できないデータ型を返す式に対するインデックスの作成時のエラーメッセージが修正されました。  (Amit Langote) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
空の列名でなく自動生成した列名が出力されるようになります。
</p>
<pre>
(修正前)
=# CREATE INDEX ON t ((ROW(c)));
ERROR:  column "" has pseudo-type record

(修正後)
=# CREATE INDEX ON t ((ROW(c)));
ERROR:  column "row" has pseudo-type record
</pre>
<li>VALUESリストのみからなるマテリアライズドビューのダンプ時に、指定した列名を出力するように修正されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<pre>
=# CREATE MATERIALIZED VIEW mv (c) AS VALUES (1);
CREATE MATERIALIZED VIEW

(修正前のpg_dump出力)
CREATE MATERIALIZED VIEW public.mv AS
 VALUES (1)
  WITH NO DATA;

(修正後のpg_dump出力)
CREATE MATERIALIZED VIEW public.mv AS
 SELECT "*VALUES*".column1 AS c
   FROM (VALUES (1)) "*VALUES*"
  WITH NO DATA;
</pre>
<li>ビューまたはルールの依存関係の計算時に xmltable関数で参照されているデータ型と照合順序を考慮するように修正されました。  (Tom Lane) (12)(11)(10)</li>
<p>
修正前は、xmltable関数で参照されているデータ型や照合順序を削除することで、ビューやルールを壊すことができました。この修正は新たに作成したビューとルールに適用され、既存のものには適用されません。
</p>
<pre>
=# CREATE EXTENSION seg;
=# CREATE TABLE t53 AS SELECT '&lt;s&gt;1 .. 2&lt;/s&gt;'::xml AS c;
=# CREATE VIEW v53 AS SELECT s::text FROM t53, xmltable('//s' PASSING c COLUMNS s seg);

(修正前)
=# DROP EXTENSION seg;
DROP EXTENSION
=# SELECT * FROM v53;
ERROR:  cache lookup failed for type 16499

(修正後)
=# DROP EXTENSION seg;
ERROR:  cannot drop extension seg because other objects depend on it
DETAIL:  view xmlview depends on type seg
HINT:  Use DROP ... CASCADE to drop the dependent objects too.
</pre>
<li>RADIUS認証のオプションのパラメータ値に対して、小文字への変換と63バイトへの切り詰めを行わないように修正されました。  (Marcos David) (12)(11)(10)</li>
<p>
修正前はパラメータ値を誤って SQL識別子として処理していました。
</p>
<li>受信した NOTIFYメッセージを ReadyForQuery 送信後でなく送信前にクライアントに送信するように修正されました。  (Tom Lane) (12)(11)(10)(9.6)</li>
<p>
この修正により、libpq のようなクライアントライブラリでは、トランザクション内で受信した通知をクライアントがトランザクション完了と判断するまで受信可能になります。実際には通知を非同期で受信する必要があるため、動作の違いはおそらくありません。ただ、セッションをまたがる通知のテストケースを作成するのに便利です。
</p>
<li>GSSAPI暗号化使用時のノンブロッキングI/O処理のバグが修正されました。  (Tom Lane) (12)</li>
<p>
この誤りにより、データが損失したり、それに伴って接続が切断したり、データを残して送信が完了したと判断してスリープ状態となったりする可能性があります。さらに、libpq では接続ごとに暗号化状態を管理できなかったため、複数の暗号化接続を使用する場合にエラーが発生する可能性があります。
</p>
<li>ビルド時に GSSAPI が無効の場合にも libpq が GSS 関連の接続パラメータを解析するように修正されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
この修正により、SSL と同様に機能が無効の場合でも、関連するすべてのパラメータを常に受けつけるようになります。
</p>
<li>ECPG の PGTYPEStimestamp_fmt_asc() 関数で、%b、%B 書式指定時の誤った処理が修正されました。  (Tomas Vondra) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
%b、%B は月の略称、名称に置換されますが、修正前は、1 始まりの月数を 0始まりの月名の配列の添字に使用しており、11月までは翌月の月名に置換され、12月はクラッシュする可能性がありました。
</p>
<li>ecpglib でメモリ不足によるエラー発生後にクラッシュが発生しないように修正されました。  (Tom Lane) (12)</li>
<li>並列の pg_dump や pg_restore でワーカプロセスの作成に失敗した場合にクラッシュや無限ループが発生しないように修正されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<li>pg_dump や pg_restore の並列実行をシグナルを介して終了しようとしたときに、クラッシュまたはハングアップが発生する可能性があり、防止されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<li>pg_upgrade で、テーブル内のアップグレードできないデータ型を調べるときに、配列と範囲のベースとなるデータ型を調べるようになりました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
複合型やドメインには対応していましたが、これらについて見逃されていました。
</p>
<li>createuser の --connection-limit オプションの引数に、より厳格な構文チェックを適用するようになりました。  (&Aacute;lvaro Herrera) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<li>より多くの場合で、PL/pgSQL の複合型変数によって参照される指定型の変更に対応できるになりました。  (Ashutosh Sharma, Tom Lane) (12)(11)</li>
<p>
PL/pgSQL の変数によって参照される複合型やテーブルを削除して再作成したとき、以下のようなエラーが生じることがありました。
</p>
<pre>
ERROR:  could not open relation with OID 34567
</pre>
<li>postgres_fdw で「UPDATE remote_tab SET (x, y) = (SELECT ...) 」などのコマンドをリモートサーバに送信しようとするときに、クラッシュしないようになりました。  (Tom Lane) (12)(11)(10)(9.6)</li>
<li>contrib/dict_int で、1 未満の maxlen 設定を拒否するようになりました。  (Tomas Vondra) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
これにより、そのパラメータの無意味な設定によるクラッシュを防止します。
</p>
<li>contrib/tablefunc の crosstab() 関数で NULL のカテゴリ値を許可しないようになりました。  (Joe Conway) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
このケースは役に立たず、一部のプラットフォームではクラッシュしました。
</p>
<li>OpenSSL の SSL_clear_options() 関数に対する configure の調査を修正して、1.1.0 より前の OpenSSLバージョンで動作するようになりました。  (Michael Paquier, Daniel Gustafsson) (12)(11)</li>
<p>
この問題により、PostgreSQL が古いバージョンの OpenSSL で構築されている場合、SSL圧縮オプションを必要に応じて設定できなくなる可能性がありました。
</p>
<li>いくつかのタイムアウトおよび統計情報収集の設定パラメータの変数をPGDLLIMPORT としてマークし、拡張機能が Windows でそれらにアクセスできるようになりました。  (Pascal Legrand) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
これは、idle_in_transaction_session_timeout、lock_timeout、statement_timeout、track_activities、track_counts、およびtrack_functions に適用されます。
</p>
<li>slabメモリコンテキストの健全性チェックでメモリリークを回避するようになりました。  (Tomas Vondra) (12)(11)(10)</li>
<p>
プロダクションビルドでは通常、メモリコンテキストチェックが有効にならないため、これは問題ではありません。ただし、デバッグビルド（--enable-cassert や-DUSE_VALGRIND）ではリークが非常に深刻になる可能性があります。
</p>
<li>LWLock 統計情報メカニズムによって報告された複数の統計情報エントリが修正されました。  (Fujii Masao) (12)(11)(10)</li>
<p>
LWLock 統計情報のコード (デフォルトではビルドされません。-DLWLOCK_STATSを使用してコンパイルする必要があります) は、ハッシュテーブルキーの作成が失敗した結果、同じ LWLock およびバックエンドプロセスの複数のエントリを報告する可能性がありました。
</p>
<li>Windows でプロセス間シグナルの配信が遅延する原因となった競合状態が修正されました。  (Amit Kapila) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
これは、NOTIFY で目に見えるタイミングの異常を引き起こし、おそらく他の誤動作も引き起こしました。
</p>
<li>Windows の ReadFile() 関数からのまれなエラー結果の処理が修正されました。  (Thomas Munro, Juan Jos&eacute; Santamar&iacute;a Flecha) (12)</li>
<p>
知られている限り、この見落としは、実際のクエリの誤動作ではなく、不要な情報を含む以下のようなログメッセージをもたらしました。
</p>
<pre>
LOG:  unrecognized win32 error code: ...
</pre>
<li>Windows で、ERROR_ACCESS_DENIED でファイルアクセスの失敗後に数回再試行するようになりました。  (Alexander Lakhin, Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
これは、対象ファイルに削除のフラグが設定されているが、実際には削除されていないためにファイルを開くことができない場合の対処に役立ちます。例えば、pg_ctl は、postmaster がすでに停止しているかどうかを調べるときに、以下ようなエラーでしばしば失敗しました。
</p>
<pre>
pg_ctl: could not open PID file "c:/pgsql/data/postmaster.pid": Permission denied
</pre>
<li>Windows で、例えば pg_ctl restart によって停止された直後にpostmaster を起動する場合に、postmaster のログファイルの共有違反を回避するようになりました。  (Alexander Lakhin) (12)</li>
</ol>

<div>
<a href="https://www.sraoss.co.jp/prod_serv/support/pgsql-mainte/?utm_source=sraoss-techblog&utm_medium=referral&utm_campaign=under-article-pgsql" rel="noopener" style="color:initial;" target="_blank" class="no-ext"></p>
<div style="background-color:#DAEFF6; padding:20px; border-radius:8px; text-align:center;">
SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。<br />
詳しくは<strong style="color:#2581c4;">弊社ホームページ</strong>をご覧ください。
</div>
<p></a>
</div>

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 9.6.16 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-6-16/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Fri, 22 Nov 2019 02:32:55 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.6]]></category>
		<category><![CDATA[PostgreSQL 9.6.15]]></category>
		<category><![CDATA[PostgreSQL 9.6.16]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=4963</guid>

					<description><![CDATA[このリリースは 9.6.15 からの修正リリース（2019年11月14日リリース）です。 9.6.x からのアップデートではダンプ、リストアは不要です。 ただし、contrib/intarray で &lt;@ 演算子に ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.6.15 からの修正リリース（2019年11月14日リリース）です。</p>
<p>9.6.x からのアップデートではダンプ、リストアは不要です。<br />
ただし、contrib/intarray で &lt;@ 演算子に GiSTインデックスを使っている場合には、下記の 83番の項目を確認してください。<br />
9.6.9 より前のバージョンからのアップデートの場合には <a href="/tech-blog/pgsql/9-6-9/">9.6.9 のリリース情報</a>も確認してください。</p>
<p><span id="more-4963"></span></p>
<h3>PostgreSQL 9.6.15 から 9.6.16 への変更点</h3>
<p>12.1、11.6、10.11、9.6.16、9.5.20、9.4.25 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<hr />
<ol>
<li>ALTER TABLE でテーブル書き換えを要する他の変更と共に、デフォルト値無しの列を追加したときのクラッシュが修正されました。  (Andres Freund) (12)</li>
<p>
以下のような発生例が報告されました。c1列の追加がテーブル書き換えを要する変更で、デフォルト値無しの列追加が c2 です。
</p>
<pre>
db=# CREATE TABLE t1 (id int);
db=# CREATE SEQUENCE seq1;
db=# ALTER TABLE t1
       ADD COLUMN c1 numeric(10,0) NOT NULL DEFAULT nextval('seq1'),
       ADD COLUMN c2 varchar(20);
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
</pre>
<li>REINDEX CONCURRENTLY のロック処理が修正されました。  (Michael Paquier) (12)</li>
<p>
REINDEX CONCURRENTLY は新たな版のインデックスに対してセッションレベルのロックを取得しておらず、潜在的に他セッションによる早すぎる操作を許していました。また、悪いタイミングでの問い合わせキャンセルや割り込みによるセッション終了により、REINDEX CONCURRENTLY が持つセッションレベルロックが解放されない恐れがありました。
</p>
<li>CREATE INDEX CONCURRENTLY や REINDEX CONCURRENTLY が進行状況を報告するときの、競合状態によるクラッシュが回避されました。  (&Aacute;lvaro Herrera) (12)</li>
<li>REINDEX CONCURRENTLY で重複した依存関係エントリが作成されてしまうのが回避されました。  (Michael Paquier) (12)</li>
<p>
この障害により pg_depend の肥大化が生じますが、それ以外の害はありません。既存の重複エントリは pg_depend システムテーブルを操作するか、インデックスを一度削除することで除去できます。
</p>
<li>VACUUM が未だ実行中のトランザクションに関連する古いマルチトランザクションIDをフリーズしようとするのが防止されました。  (Nathan Bossart, Jeremy Schneider) (12)(11)(10)(9.6)(9.5)</li>
<p>
この障害により、古い実行中のトランザクションが終了するまでの間、VACUUM が失敗していました。
</p>
<p>
VACUUM 実行で以下のようなエラーが出るケースが報告されました。
</p>
<pre>
ERROR:  multixact ... from before cutoff ... found to be still running
</pre>
<li>式インデックスに対して CLUSTER を実行する時の、「wrong type of slot」エラーが修正されました。  (Andres Freund) (12)</li>
<p>
CLUSTERコマンドで以下のような予期せぬメッセージが発生していました。
</p>
<pre>
ERROR:  trying to store a heap tuple into wrong type of slot
</pre>
<li>パーティションテーブルに対する SET CONSTRAINTS ... DEFERRED が失敗していたものが修正されました。  (&Aacute;lvaro Herrera) (12)(11)</li>
<p>
トリガが無い、という不適切なエラーが生じていました。以下に発生例を示します。
</p>
<pre>
db=# CREATE TABLE t7p (a int PRIMARY KEY) PARTITION BY LIST (a);
db=# CREATE TABLE t7p12 PARTITION OF t7p FOR VALUES IN (1, 2)
                        PARTITION BY LIST (a);
db=# CREATE TABLE t7p1 PARTITION OF t7p12 FOR VALUES IN (1);
db=# CREATE TABLE t7p2 PARTITION OF t7p12 FOR VALUES IN (2);
db=# CREATE TABLE t7p3 PARTITION OF t7p FOR VALUES IN (3);
db=# CREATE TABLE t7fk (a int REFERENCES t7p DEFERRABLE INITIALLY IMMEDIATE);
db=# BEGIN;
db=# SET CONSTRAINTS t7fk_a_fkey DEFERRED;
ERROR:  no triggers found for constraint with OID 24861
</pre>
<li>親のパーティションテーブルに削除された列が含まれている場合に生じる、パーティションのインデックスを作る際のエラーが修正されました。  (Michael Paquier) (12)(11)</li>
<p>
条件に該当するCREATE INDEXコマンドに対して以下のような予期せぬエラーが出るケースが報告されました。
</p>
<pre>
ERROR:  unexpected varattno 4 in expression to be mapped
</pre>
<li>パーティションテーブルでインデックスのある列の削除について修正されました。  (Amit Langote, Michael Paquier) (12)</li>
<p>
これまではインデックスの依存性に関するエラーを出して失敗していましたが、自動的にインデックスも削除されるべきでした。
</p>
<li>パーティションインデックスが、インデックス同時再作成に失敗した後に削除できるようになりました。  (Michael Paquier) (12)</li>
<p>
このような場合に、インデックスの pg_class.relispartition フラグが誤った状態で残っていて、DROP INDEX の失敗をもたらしていました。DROP INDEX で、以下のようなエラーが出る動作が報告されました。
</p>
<pre>
ERROR:  could not find tuple for parent of relation ...
</pre>
<li>パーティション単位での結合(partition-wise join)で、同値クラスメンバーの処理が修正されました。  (Amit Langote) (12)</li>
<p>
この誤りで、本来可能なパーティション単位での結合プランを使えなくなるか、「could not find pathkey item to sort」というプランナのエラーになる可能性があります。
</p>
<li>問い合わせの式が操作されているときに、WINDOW句でオフセット式が確実に処理されるようになりました。  (Andrew Gierth) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
この誤りは、オフセットが自明でない式のときに様々なエラーをひき起こす可能性がありました。一例として、関数内の問い合わせが WINDOW句のオフセット式で関数パラメータを参照していて、関数がインライン化されている場合に以下のようなエラーを出すことがありました。
</p>
<pre>
ERROR:  no value found for parameter 1
</pre>
<li>子プロセス配列に空き枠が無いときにパラレル問い合わせがバックグラウンドワーカを要求した場合の、postmaster (サーバの親プロセス) のエラーが回避されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)</li>
<p>
以下のエラーが発生するケースが報告されました。稀ですが本障害で postmaster のクラッシュをひき起こす可能性もあります。
</p>
<pre>
FATAL:  no free slots in PMChildFlags array
</pre>
<li>BEFORE UPDATEトリガを伴うテーブルの EvalPlanQual再チェックでひき起こされるクラッシュが修正されました。  (Andres Freund) (12)</li>
<p>
本障害で更新SQL処理のバックエンドプロセスのクラッシュが生じます。EvalPlanQual再チェックは、READ COMMITTEDトランザクション隔離レベルでのSQL実行における内部的な処理です。
</p>
<li>問い合わせが TOASTテーブルにアクセスしようとしたときの、「unexpected relkind」エラーが修正されました。  (John Hsu, Michael Paquier, Tom Lane) (12)(11)</li>
<p>
本来、権限が無いというエラーが出るべきところで、不適切なエラーが出ていました。
</p>
<pre>
（本障害によるエラー例）
db=&gt; REINDEX TABLE pg_toast.pg_toast_16388;
ERROR:  unexpected relkind: 116

（本来生じるべきエラーは以下）
ERROR:  must be owner of table pg_toast_16388
</pre>
<li>パラレルワーカ起動時に GUCパラメータを設定する際のエラー発生時に、関連するエラーコンテキスト行を出力するようになりました。  (Thomas Munro) (12)(11)(10)(9.6)(9.5)</li>
<p>
設定パラメータの誤りでパラレル問い合わせがエラーになったときに、エラーメッセージから誤っている個所が分かりにくいという問題がありました。
</p>
<li>read/write でオープンされたファイルにだけ fsync() が適用されるようになりました。  (Andres Freund, Michael Paquier) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
一部のコードパスではリードオンリーで開いたファイルにも fsync() を試みていました。これは一部プラットフォームではエラーをひき起こし、サービスダウンの原因となりました。
</p>
<pre>
(Windowsプラットフォームで以下PANICの発生が報告されました)
PANIC:  could not fsync file "pg_replslot/xxx/state": Bad file descriptor
</pre>
<li>文字エンコーディング変換が以前より長い文字列を扱えるようになりました。  (&Aacute;lvaro Herrera, Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
これまでは入力文字列で 0.25GB が上限でしたが、これからは変換後の出力が1GB を超えない限り処理できるようになります。
</p>
<li>ウィンドウ関数で不要に巨大なタプルストアが作成されるのが回避されました。  (Andrew Gierth) (12)(11)(10)(9.6)</li>
<p>
タプルストアとは、問い合わせの中間結果の表形式データを格納する領域です。一部の場合にタプルストアがソーステーブルの、問い合わせに必要な列だけではなく、全列を含むことがありました。
</p>
<p>
本修正は問い合わせで生じる不要に大きい一時ファイルを小さくします。
</p>
<li>repalloc() がサイズを大幅に縮小したときには、システムにメモリ空間を返却するようになりました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
repalloc() は PostgreSQL のメモリマネージャモジュールが提供する標準ライブラリの realloc() に似た動作をする関数です。
</p>
<li>アーカイブリカバリの最後に、一時的な WAL とヒストリファイルが確実に削除されるようになりました。  (Sawada Masahiko) (12)(11)(10)(9.6)(9.5)</li>
<p>
これまで、アーカイブリカバリ後のオンラインWALディレクトリにRECOVERYHISTORYファイルが残る動作がありました。
</p>
<li>recovery_min_apply_delay設定が有効な場合のアーカイブリカバリでのエラーが回避されました。  (Fujii Masao) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
recovery_min_apply_delay はアーカイブリカバリの際の設定では通常使われませんが、動作すべきでした。これまでは設定すると常にアーカイブリカバリに失敗し、アサート有効のビルドではアサート失敗が生じました。
</p>
<li>クラッシュリカバリ時には、restore_command、recovery_end_command、recovery_min_apply_delay の設定が無視されるようになりました。  (Fujii Masao) (12)</li>
<p>
これらは バージョン12 から postgresql.conf に記述するようになったため、クラッシュリカバリ時にも有効になっていることが有り得ますが、このときこれら設定に従うことは望ましくありません。クラッシュリカバリが完了するまで、これらの設定は無視されるようになります。
</p>
<li>パブリッシャとサブスクライバがテーブルの REPLICA IDENTITY列について異なる認識を持っている場合のロジカルレプリケーションのエラーが修正されました。  (Jehan-Guillaume de Rorthais, Peter Eisentraut) (12)(11)(10)</li>
<p>
パブリッシャにその列が存在しないときに、サブスクライバで REPLICA IDENTITYの一部として列を宣言すると、下記のエラーをひき起こしました。
</p>
<pre>
ERROR:  negative bitmapset member not allowed
</pre>
<li>ロジカルレプリケーションの walsenderプロセスの停止における不要な遅延が回避されました。  (Craig Ringer, &Aacute;lvaro Herrera) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
これまでは場合によっては wal_sender_timeout の時間だけ停止が滞留することがあり、PostgreSQLサービス停止を遅らせました。
</p>
<li>ロジカルレプリケーションの walreceiverプロセスでタイムアウト処理が修正されました。  (Julien Rouhaud) (12)(11)(10)</li>
<p>
誤ったロジックがロジカルレプリケーションにおけるwal_receiver_timeout の働きを妨げていました。パブリッシャ側の walsender が終了したのにサブスクライバ側のlogical worker が待ち続けるという動作が報告されました。
</p>
<li>ロジカルデコーディングに対するレプリケーションメッセージに正しくタイムスタンプを付与するように修正されました。  (Jeff Janes) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
この誤りで、例えば pg_stat_subscription.last_msg_send_time がたいてい NULL になりました。
</p>
<li>バックエンドプロセスがそれまで同期レプリケーションが発生するのを待機していたとき、バックエンド終了時の競合状態が修正されました。  (Dongming Liu) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
この障害によりバックエンドプロセス終了が遅くなりました。
</p>
<li>PAM認証が使われているとき、接続中断についてログメッセージを出さないようになりました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
libpqベースのクライアントは一般的に、最初の接続試行が失敗するまでユーザにパスワード入力を促さないため、パスワードが必要な場合には二回接続を試みます。それゆえ、サーバはクライアントがパスワードを要する接続を閉じたときに無駄なログメッセージを出さないように書かれています。しかしながら、PAM認証ではそのようになっておらず、余計な認証失敗メッセージを複数出力していました。
</p>
<li>bitshiftright() の誤動作が修正されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
bitshiftright() はビット列データ型（bit、bit varying）の右シフト演算子の実装関数です。ビット列の長さが 8 の倍数ではないときに、結果の最終バイトにあるシフトされた桁のゼロ埋めに失敗していました。
</p>
<p>
ほとんどの場合、異常になるのは不可視部分のデータです。しかし、ビット列比較では余分なビットも無視されず、常に 0 であると想定されるところに非ゼロビットが存在することで予期せぬ比較動作が生じます。
</p>
<p>
ビット列の右シフト結果をテーブルに格納している場合、不整合データを以下のような SQL で補正できます。
</p>
<pre>
UPDATE mytab SET bitcol = ~(~bitcol) WHERE bitcol != ~(~bitcol);
</pre>
<li>文字列の position()関数（あるいは strpos()関数）の空の検索文字列に対する結果が修正されました。  (Tom Lane) (12)</li>
<p>
歴史的に、また、SQL標準により、このような場合に結果は 1 であるべきですが、12.0 では 0 を返していました。
</p>
<pre>
(以下の応答は 1 が正しい)
db=# SELECT strpos('ABCDE', '');
 strpos
--------
      0
(1 row)
</pre>
<li>interval型の掛け算で境界値の整数オーバーフローの検出が修正されました。  (Yuya Watari) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<pre>
（オーバーフローが検出されない例)
db1=# SELECT extract(epoch from '256 microseconds'::interval * (2^55)::float8);
     date_part
--------------------
 -9223372036854.775
(1 row)

(修正後は以下エラーがでるようになります)
ERROR: interval out of range
</pre>
<li>ispell のテキスト検索辞書が誤った接辞データを含む場合にクラッシュすることがあり、回避されました。  (Arthur Zakirov) (12)(11)(10)(9.6)</li>
<li>GiSTインデックスを VACUUMするときのメモリリークが回避されました。  (Dilip Kumar) (12)</li>
<li>Windowsで、「Norwegian (Bokm&aring;l) 」ロケール名の追加の書き方も認識するようになりました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
括弧を記載しない書き方も受け入れるようになりました。
</p>
<li>libpq が整数パラメータの文字列に末尾の空白を許容するように修正しました。  (Michael Paquier) (12)</li>
<p>
バージョン12で整数パラメータの検査が厳しくなっていましたが、末尾の空白まで許容しないのは望ましくないと判断されました。
</p>
<li>libpq で、構文的に無効な connect_timeoutパラメータ値によってひき起こされたエラーの後に CONNECTION_BAD接続状態を正しく報告するようになりました。  (Lars Kanis) (12)</li>
<p>
これまでは接続状態に CONNECTION_BAD がセットされませんでした。
</p>
<li>ENABLE_NLS が定義されていて、ECPGクライアントが ecpglib.h を含む場合のコンパイル失敗が回避されました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
ecpg_gettext() の定義をクライアントコードから見えない適切な位置に移すことで修正されています。
</p>
<li>パーティションテーブルの外部キー制約について、パラレルリストアのスケジューリングが修正されました。  (&Aacute;lvaro Herrera) (12)</li>
<p>
pg_dump がパーティションテーブルの外部キーについて完全な依存情報の出力に失敗していました。このため、pg_restore で早すぎるタイミングで外部キー制約を再作成しようとして、パラレルリストアが時々失敗することがありました。
</p>
<li>pg_dump で、似た名前のトリガと行単位セキュリティポリシーオブジェクトについて、安定した出力順序が保証されました。  (Benjie Gillam) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
これまでは、同じ名前を持ち異なるテーブルに付く二つのトリガは OID でソートされましたが、これからはテーブル名でソートされます。RLS（行単位セキュリティポリシー）についても同様です。
</p>
<li>PostgreSQL 12 から sql_identifier型の元となる型がvarchar型から name型に変更されため、pg_upgrade で sql_identifier型の列を持つテーブルが拒否されるようになりました。  (Tomas Vondra) (12)</li>
<li>line型など表現が変更されたデータ型に対して、pg_upgrade のチェックが改善されました。  (Tomas Vondra) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
以前は、データ型がドメインや複合型の格納列が元となっている場合に誤判定をして、本来不要な pg_upgrade 失敗をひき起こしたり、pg_upgrade 実行後のクラスタを壊してしまったりすることがありました。
</p>
<li>--dry-runオプション付きの pg_rewind で pg_control の更新を避けるようになりました。  (Alexey Kondratov) (12)</li>
<p>
これは、それに続く pg_rewind の実行の失敗につながる可能性がありました。
</p>
<li>-sオプション付きの pg_waldump の不具合が修正されました。  (Andrey Lepikhov) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
継続WALレコードがページの境界で丁度終わるような特別なケースの場合、-sオプションによりそのWALレコードを指定した際に正常にレコードを処理できずアサーションエラーが発生していました。
</p>
<li>--bkp-detailsオプション付きの pg_waldump でフルページライトを伴うWALレコードに対する余分な改行の出力を避けるようになりました。  (Andres Freund) (12)(11)(10)(9.6)(9.5)</li>
<li>pg_waldump での小さなメモリリークが修正されました。  (Andres Freund) (12)(11)(10)(9.6)(9.5)</li>
<li>pqsignal() がエクスポートされた libpq のシンボルとして復帰しました。  (Tom Lane) (12)</li>
<p>
この関数は、どのクライアントも使用しないであろうという理由で以前に削除されましたが、とても古いバージョンの psql（および、おそらく他のアプリケーション）と組み合わせて使用した際に正常に動作しなくなってしまいました。
</p>
<li>libperl の存在有無に対する configure のテストが修正され、最近の RedHat のリリースでも動作するようになりました。  (Tom Lane) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
以前では、ユーザがCFLAGSに -O0 を設定した場合に失敗する可能性がありました。
</p>
<li>PowerPC上におけるスピンロックの正しいコード生成が保証されました。  (Noah Misch) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
以前のスピンロックのコードでは、それが許容されないアセンブリ命令に対してレジスタ0 を選択できたため、ビルドの失敗を引き起こしてました。
</p>
<p>
このバグに一致する報告は今までに 1回のみでしたが、修正された PostgreSQL のコードや変則的なコンパイラオプションによるビルドを実行した際に問題を起こす可能性がありました。
</p>
<li>AIX上で -qsrcmsgコンパイラオプションを使用しなくなりました。  (Noah Misch) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<p>
これにより xlc v16.1.0 での内部的なコンパイルエラーが避けられます。この変更は、コンパイラのエラーメッセージ形式が変わること以外ほとんど影響はありません。
</p>
<li>OpenSSL のファイルパス上に空白がある場合にも処理できるようにMSVC のビルド処理が修正されました。  (Andrew Dunstan) (12)(11)(10)(9.6)(9.5)(9.4)</li>
<li>カスタムリレーションオプションを設定するALTER TABLE ... SET ... の不具合が修正されました。  (Michael Paquier) (11)(10)(9.6)</li>
<p>
bloom_index専用のオプションなど、特殊なオプションを ALTER TABLE で変更した場合に失敗することがありました。
</p>
<pre>
（報告されたエラー例）
ERROR:  XX000: unrecognized lock mode: 2139062143
</pre>
<li>すべての親テーブルが変更されていない限り、多重に継承された列の型の変更が許可されなくなりました。  (Tom Lane) (11)(10)(9.6)(9.5)</li>
<p>
無関係な複数の親テーブルを継承した子テーブルがあって、継承した列が重複している場合、親テーブルでその列の型の変更するとエラーが返されるようになりました。以前は実行可能でしたが、そうすると、同期が取れなくなった親への問い合わせが失敗していました。
</p>
<pre>
（該当する操作の例）
db=# CREATE TABLE pt53_1 (f1 int, f2 int);
db=# CREATE TABLE pt53_2 (f1 int, f3 bigint);
db=# CREATE TABLE ct53 (f4 int) INHERITS (pt53_1, pt53_2);
NOTICE:  merging multiple inherited definitions of column "f1"
db=# ALTER TABLE pt53_1 ALTER COLUMN f1 TYPE bigint;
ERROR:  cannot alter inherited column "f1" of relation "ct53"
</pre>
<p>
いったん ALTER TABLE .. NO INHERIT .. で継承関係を外して、各テーブルでデータ型を変更して、ALTER TABLE .. INHERIT .. で再び継承関係を付与するという手順で同様の操作を行うことができます。
</p>
<li>トランザクション内の ANALYZEコマンドで同じテーブルが 2回指定された場合のエラーが回避されました。  (Tom Lane) (11)</li>
<p>
これまでは以下のようなエラーが生じていました。
</p>
<pre>
db=# CREATE TABLE t54 (id int);
db=# INSERT INTO t54 VALUES (1), (2);
db=# BEGIN;
db=# ANALYZE t54,t54;
ERROR:  duplicate key value violates unique constraint "pg_statistic_relid_att_inh_index"
DETAIL:  Key (starelid, staattnum, stainherit)=(16391, 1, f) already exists.
</pre>
<li>ICU照合を用いた ILIKE文で大文字小文字を区別できるようプランナーのテストが修正されました。  (Tom Lane) (11)(10)</li>
<p>
プランナは ICU照合が使われていた場合に、大文字小文字が区別できるかを適切に判定できていなかったため、多くのパターンで固定された接頭語として扱ってしまい、ILIKE句から派生したインデックススキャン時に見つけるべきエントリを見逃す可能性がありました。
</p>
<pre>
（誤動作例）
db=# CREATE TABLE t55 (
       normal text UNIQUE, icu text COLLATE "de-x-icu" UNIQUE);
db=# INSERT INTO t55 VALUES ('ABC', 'ABC');
db=# SELECT * FROM t55 WHERE normal ILIKE 'abc';
 normal | icu 
--------+-----
 ABC    | ABC
(1 row)

db1=# SELECT * FROM t55 WHERE icu ILIKE 'abc';
 normal | icu 
--------+-----
(0 rows)
</pre>
<li>WITH CHECK OPTION式と行セキュリティポリシーの式における行全体の変数の扱いが修正されました。  (Andres Freund) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
以前は、行セキュリティポリシーが設定されていた場合に、行タイプの不一致に関する偽のエラーが生じる可能性がありました。
</p>
<pre>
（エラー発生例）
db=&gt; CREATE TABLE t56 (a int, b int, c int);
db=&gt; CREATE POLICY p56 ON t56 USING (t56 &gt;= ROW(1,1,1));
db=&gt; ALTER TABLE t56 ENABLE ROW LEVEL SECURITY;
db=&gt; ALTER TABLE t56 FORCE ROW LEVEL SECURITY;
db=&gt; INSERT INTO t56 SELECT 10, 20, 30;
db=&gt; INSERT INTO t56 SELECT * FROM (SELECT b, c FROM t56 ORDER BY a) ss;
ERROR:  table row type and query-specified row type do not match
DETAIL:  Table row contains 2 attributes, but query expects 3.
（3番目の値を NULL として INSERT に成功する動作が正しい）
</pre>
<li>BEFORE UPDATEトリガが古いタプルをそのまま返し、それが最後のトリガではない場合のダブルフリーが防止されました。  (Thomas Munro) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
該当の場合にバックエンドプロセスがクラッシュする可能性がありました。
</p>
<li>x = ANY(配列)、もしくは同様の操作で、定数の NULL配列が含まれる場合のクラッシュが修正されました。  (Tom Lane) (11)</li>
<p>
以下の形の SQL でクラッシュが報告されました。
</p>
<pre>
SELECT * FROM t58 WHERE x = ANY(NULL::bigint[]);
</pre>
<li>SERIALIZABLEモードで、確実に正しい行バージョンで行レベルの述語ロックが取得されるように修正されました。  (Thomas Munro, Heikki Linnakangas) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
可視の行バージョンが HOT更新された場合、デッドタプルとなった以前のバージョンでロックが取得されるかもしれず、直列化の保証に微妙に失敗する可能性がありました。
</p>
<li>HOTによるヒープページ除去中の不要なカタログ参照が回避されました。  (Thomas Munro) (11)(10)</li>
<p>
このタイミングでログに記録されないインデックスの検査をする必要はありませんでした。この検査はいくつかのワークロードでかなりのパフォーマンスの問題を引き起こしていました。また、理論的にはデッドロックを引き起こす可能性もありました。
</p>
<li>ハッシュテーブルをグループ化するための JITコンパイルの等値比較の失敗が修正されました。これは性能低下をもたらしていました。  (Andres Freund) (11)</li>
<li>ロジカルデコーディングで、スナップショットの再構築時にサブトランザクションが正しく考慮されるようになりました。  (Masahiko Sawada) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
この誤りはアサート失敗をもたらします。アサートを無効にした本番ビルドに悪影響があるかどうかは不明です。
</p>
<li>ALTER SYSTEM で postgresql.auto.conf の重複エントリに対処するようになりました。  (Ian Barwick) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
ALTER SYSTEM自体ではそのような状態は発生しませんが、postgresql.auto.conf を変更する外部ツールでは発生する可能性があります。対象パラメータの重複したエントリが削除され、新しい設定が (ある場合) 最後に追加されるようになります。
</p>
<p>
これまでは ALTER SYSTEMコマンドは重複エントリに対して、実際に適用されるのは末尾エントリであるにもかかわらず、先頭のエントリだけを書き換えしていました。
</p>
<li>設定ファイルで空のファイル名を持つ include ディレクティブを拒否し、再帰的なファイルのインクルードをより明確に報告するようになりました。  (Ian Barwick, Tom Lane) (11)(10)(9.6)(9.5)</li>
<p>
以下にメッセージの違いを示します。
</p>
<pre>
(変更前: include = '')
LOG:  input in flex scanner failed at file "/var/lib/pgsql/11/data" line 1
FATAL:  configuration file "/var/lib/pgsql/11/data/postgresql.conf" contains errors

(変更前: include = '/var/lib/pgsql/11/data/postgresql.conf')
LOG:  could not open configuration file "postgresql.conf": maximum nesting depth exceeded
FATAL:  configuration file "/var/lib/pgsql/11/data/postgresql.conf" contains errors

(変更後: include = '')
LOG:  empty configuration file name: ""
FATAL:  configuration file "/var/lib/pgsql/11/data/postgresql.conf" contains errors

(変更後: include = '/var/lib/pgsql/11/data/postgresql.conf')
LOG:  configuration file recursion in "/var/lib/pgsql/11/data/postgresql.conf"
FATAL:  configuration file "/var/lib/pgsql/11/data/postgresql.conf" contains errors
</pre>
<li>time with time zone 入力で不完全な日付指定が検出されないいくつかのケースが修正されました。  (Alexander Lakhin) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
時期によって変化する UTCオフセットを持つ時間帯が指定されている場合、オフセットを解決できるように日付も必要です。使用される構文によっては、この検査が強制されず、誤った出力が生成される場合がありました。
</p>
<pre>
(誤動作の例)
=# SELECT '12:53:57 m11'::timetz;
      timetz
-------------------
 12:53:57+09:18:59
(1 row)

(エラーになるのが修正後の正しい動作です)
ERROR:  invalid input syntax for type time with time zone: "12:53:57 m11"
</pre>
<li>json[b]_populate_record() および json[b]_populate_recordset() のAS句から型情報を取得する機能が復元されました。  (Tom Lane) (11)</li>
<p>
レコード引数が NULL であり、複合型が宣言されていない場合は、代わりに AS句を使用してみてください。これは推奨される使用法ではありませんが、バージョン11 より前は機能しており、今では再び使用できます。AS句を使用するなら、json[b]_to_record() 関数を使用すべきです。
</p>
<pre>
(変更前)
=# SELECT * FROM json_populate_record(null::record, '{"a":1,"b":2}')
     AS x(a int, b int);
ERROR:  record type has not been registered

(変更後)
=# SELECT * FROM json_populate_record(null::record, '{"a":1,"b":2}')
     AS x(a int, b int);
 a | b
---+---
 1 | 2
(1 row)

(推奨される方法)
=# SELECT * FROM json_to_record('{"a":1,"b":2}') AS x(a int, b int);
 a | b
---+---
 1 | 2
(1 row)
</pre>
<li>XMLTABLE で名前空間ノードを選択する際のクラッシュが修正されました。  (Chapman Flack) (11)(10)</li>
<pre>
(クラッシュの再現例)
=# SELECT * FROM xmltable('.' PASSING '&lt;foo/&gt;'
                          COLUMNS a text PATH 'foo/namespace::node()');
server closed the connection unexpectedly
</pre>
<li>ICU 照合を使用する場合の lower()、upper()、および initcap()関数のメモリリークが修正されました。  (Konstantin Knizhnik) (11)(10)</li>
<li>GIN ポスティングリストの誤った圧縮ロジックが修正されました。  (Heikki Linnakangas) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
GIN ポスティングリストの項目は、隣接するインデックス付き TID間の距離が16TB を超える場合、7 バイトを必要とします。ロジックの 1 つのステップがそれと同期していなかったため、6バイトのバッファに値を書き込もうとする可能性がありました。原則としてこれはスタックオーバーランを引き起こす可能性がありますが、ほとんどのアーキテクチャでは、次のバイトが未使用のアライメントパディングである可能性が高く、バグは無害です。いずれにせよバグに遭遇することは稀です。
</p>
<li>KNN-GiST の Infinity、NaN、および NULL 値の処理が修正されました。  (Alexander Korotkov) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
NULL 以外の列値に対して計算された距離の一部が Infinity または NaN である場合、問い合わせの出力順序が誤っている（通常の並び替えの結果とは異なる）可能性があります。
</p>
<p>
以下に順序が異常である例を示します。
</p>
<pre>
(変更前)
=# SELECT * FROM point_tbl ORDER BY f1 &lt;-&gt; '0,1';
        f1
-------------------
 (10,10)
 (NaN,NaN)
 (0,0)
 (1e-300,-1e-300)
 (-3,4)
 (-10,0)
 (-5,-12)
 (5.1,34.5)

 (1e+300,Infinity)
(10 rows)

(修正後)
=# SELECT * FROM point_tbl ORDER BY f1 &lt;-&gt; '0,1';
        f1
-------------------
 (0,0)
 (1e-300,-1e-300)
 (-3,4)
 (-10,0)
 (10,10)
 (-5,-12)
 (5.1,34.5)
 (1e+300,Infinity)

 (NaN,NaN)
(10 rows)
</pre>
<li>GiST および SP-GiST インデックスを使った KNN検索で、NULL の処理が修正されました。  (Nikita Glukhov) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
NULL をインデックスのサポート関数まで廻さないようにして、クラッシュの可能性を回避します。
</p>
<li>psqlで、予期しない接続の切断と再接続の成功後に、サーバに関する内部状態を再同期するようになりました。  (Peter Billen, Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
通常は内部状態は変わらないため再同期は不要です。しかし、接続がいくつかのサーバの内の 1つにつながる場合など、稀なケースでは問題になる可能性がありました。
</p>
<p>
この変更により、psql は、たとえば SSL が使用されているかどうかなど、起動時に発行される対話型メッセージを再発行します。
</p>
<pre>
（問題の再現例）
$ psql
psql (11.5)
Type "help" for help.

postgres=#

（ここでPostgreSQL11サーバを停止して、PostgreSQL12サーバを起動する）

postgres=# SELECT 1; 
FATAL:  terminating connection due to administrator command
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: Succeeded.

postgres=# df
ERROR:  column p.prokind does not exist
LINE 5:  CASE p.prokind
              ^
HINT:  Perhaps you meant to reference the column "p.probin".

（サーバが変わったことを認識していないためエラーが生じました）
</pre>
<li>psql でプラットフォーム固有の NULL ポインタ参照が修正されました。  (Quentin Rameau) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
「psql -f」など、引数のあるオプションを引数無しで渡したときに、musl の libc ライブラリでクラッシュしました。
</p>
<li>pg_dump が 8.3 より前のサーバに対して再び動作するように修正されました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
以前の修正により、pg_dump は常に pg_opfamily を参照するようになりましたが、そのカタログはバージョン 8.3 より前には存在しませんでした。
</p>
<li>pg_restore で、「-f -」を標準出力への出力と解釈するようになりました。  (&Aacute;lvaro Herrera) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これにより、pg_restore の動作が他のいくつかのアプリケーションと統一されます。特に、12 より前のバージョンは 12 の pg_restore と同様に動作し、複数の PostgreSQL バージョン間で動作するダンプ/リストアスクリプトの作成が簡単になります。この変更の前、pg_restore はそのようなオプションを - という名前のファイルへの出力を意味すると解釈していましたが、それを望む人はほとんどいませんでした。
</p>
<li>pg_basebackup中のファイル読み取りエラーを検出するようになりました。  (Jeevan Chalke) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これまではファイル読み取りエラーを、読み取り中のファイル内容削除と見做して、無視していました。今後はそれ以外のケースについてエラーを出すようになります。
</p>
<li>pg_basebackup で、バックアップが終了するまで出力ファイルをfsync しないようになりました。  (Michael Paquier) (11)(10)</li>
<p>
fsync が遅い場合、以前のコーディングではタイムアウトエラーが発生する可能性がありました。
</p>
<li>pg_rewind で起動中の同期元クラスタを使用した場合に、pg_dump と同様にタイムアウトを無効にするようになりました。  (Alexander Kukushkin) (11)(10)(9.6)(9.5)</li>
<li>pg_waldump で、btree ページ分割レコードに newitemoff フィールドを含めるようになりました。  (Peter Geoghegan) (11)(10)(9.6)(9.5)</li>
<li>vacuumdb で --jobs オプションに大きな値を使用した場合にファイル記述子の不足をより適切に処理するように修正されました。  (Michael Paquier) (11)(10)(9.6)(9.5)</li>
<p>
ジョブ数が多すぎるエラーを出すかどうかの判断を、より正確にファイル記述子の数を調べて行うように変更されました。
</p>
<li>PL/pgSQL で複合型の置換をより適切に処理するように修正されました。  (Tom Lane) (11)</li>
<p>
複合型が完全に削除され、PL/pgSQL 関数の実行の間に同じ名前の新しい型が作成される場合が対象となります。複合型の変数は、新しい定義に一致するように更新されます。
</p>
<li>contrib/amcheck でホットスタンバイ中にログ取得なし（UNLOGGED）インデックスをスキップするように修正されました。  (Andrey Borodin, Peter Geoghegan) (11)(10)</li>
<p>
ログ取得なしインデックスには、この状況で有効なデータが含まれているとは限らないため、チェックしなくなりました。
</p>
<li>contrib/intarray の GiST 演算子クラスが修正され、空配列が &lt;@ で失敗しないようになりました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
array_column &lt;@ constant_array のような句はインデックス可能と見なされますが、インデックス検索では空の配列値が見つからない場合があります。
</p>
<p>
このための唯一の実用的なバックパッチ可能な修正では、&lt;@ のインデックス検索でインデックス全体をスキャンする必要があります。つまり、単純なシーケンシャルスキャンよりも問い合わせの性能が低下する可能性が高いことを意味します。
</p>
<p>
この変更によって性能に悪影響が及ぶアプリケーションには、いくつかの選択肢があります。このバグのない GIN インデックスに切り替えるか、array_column &lt;@ constant_array をarray_column &lt;@ constant_array AND array_column && constant_array に置き換えることができます。これにより、以前とほぼ同じ性能が得られ、指定された定数配列の空ではないすべてのサブセットが検索されます。
</p>
<li>PowerPC で、xlc コンパイラの __fetch_and_add() 関数に依存しないようになりました。  (Noah Misch) (11)(10)(9.6)(9.5)</li>
<p>
xlc 13 以降では、この関数を PostgreSQL での使用方法と互換性のない方法で解釈するため、使用できない PostgreSQL のビルドが発生しました。代わりにカスタムアセンブリコードを使用して修正されました。
</p>
<li>タイムゾーンデータファイルが tzdata release 2019c に更新されました。   (11)(10)(9.6)(9.5)(9.4)</li>
<p>
フィジーおよびノーフォーク島の夏時間法の変更に加えて、アルバータ、オーストリア、ベルギー、ブリティッシュコロンビア、カンボジア、香港、インディアナ（ペリー郡）、カリーニングラード、ケンタッキー、ミシガン、ノーフォーク島、韓国およびトルコの歴史的な修正が含まれます。</p>
<li>pg_dump でビューの循環的な依存関係の処理が修正されました。  (Tom Lane) (9.6)(9.5)(9.4)</li>
<p>
場合によっては、ビューは、pg_dump がビューよりも後にダンプする必要があるオブジェクトに依存する場合があります。最も一般的な例は、主キー列で GROUP BY を使用する問い合わせが、主キーなしでは意味的に無効である可能性があることです。これは、ビューの列名と型を確定するだけのダミーの CREATE VIEW コマンドを発行し、その後、完全なビュー定義で CREATE OR REPLACE VIEW を発行することで処理されます。以前は、ダミー定義は実際には CREATE TABLE コマンドであり、これは後の CREATE RULE コマンドによって自動的にビューに変換されました。新しいアプローチは、PostgreSQL バージョン 10 以降で正常に使用されています。以前の方法ではビューのレプリカアイデンティティの状態に関して誤ったエラーメッセージが発生するという報告のため、古いリリースにパッチが適用されました。また、この変更により、このようなビューを含むリストア中に --clean オプションを使用しようとする際の問題も回避されます。
</p>
<pre>
（変更前のダンプ出力）
$ pg_dump

CREATE TABLE public.v (
    c1 integer,
    c2 text
);

COPY public.t (c1, c2) FROM stdin;
.

ALTER TABLE ONLY public.t
    ADD CONSTRAINT t_pkey PRIMARY KEY (c1);

CREATE RULE "_RETURN" AS
    ON SELECT TO public.v DO INSTEAD  SELECT t.c1,
    t.c2
   FROM public.t
  GROUP BY t.c1;

（変更後のダンプ出力）
$ pg_dump

CREATE VIEW public.v AS
SELECT
    NULL::integer AS c1,
    NULL::text AS c2;

COPY public.t (c1, c2) FROM stdin;
.

ALTER TABLE ONLY public.t
    ADD CONSTRAINT t_pkey PRIMARY KEY (c1);

CREATE OR REPLACE VIEW public.v AS
 SELECT t.c1,
    t.c2
   FROM public.t
  GROUP BY t.c1;
</pre>
<li>python3 または python2 しか見つからない場合に configure --with-python が成功するようになりました。  (Peter Eisentraut, Tom Lane) (9.6)(9.5)(9.4)</li>
<p>
python、python3、python2 の順番で検索し、configure が、単なる python という名前の実行ファイルが存在しないという、ごく一般的な状況で成功するようになりました。PYTHON 環境変数を設定することにより、この選択をオーバライドすることも可能です。
</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 9.6.15 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-6-15/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Thu, 22 Aug 2019 01:02:01 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.6]]></category>
		<category><![CDATA[PostgreSQL 9.6.14]]></category>
		<category><![CDATA[PostgreSQL 9.6.15]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=3771</guid>

					<description><![CDATA[このリリースは 9.6.14 からの修正リリース（2019年8月8日リリース）です。 9.6.x からのアップデートではダンプ、リストアは不要です。 9.6.9 より前のバージョンからのアップデートの場合には 9.6.9 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.6.14 からの修正リリース（2019年8月8日リリース）です。</p>
<p>9.6.x からのアップデートではダンプ、リストアは不要です。<br />
9.6.9 より前のバージョンからのアップデートの場合には <a href="/tech-blog/pgsql/9-6-9/">9.6.9 のリリース情報</a>も確認してください。</p>
<p><span id="more-3771"></span></p>
<h3>PostgreSQL 9.6.14 から 9.6.15 への変更点</h3>
<p>11.5、10.10、9.6.15、9.5.19、9.4.24 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<hr />
<ol>
<li>関数風のキャスト構文を使うとき、一時データ型へのキャストではスキーマ修飾を必須とするようになりました。(CVE-2019-10208) (Noah Misch) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
一時関数の発効には長らく、pg_temp.func_name(args) という明示的な一時スキーマの指定が必要でした。これは、pg_temp.type_name(arg) と関数風の構文を使って一時データ型にキャストする場合も同様に必要です。そうでないと一時オブジェクトを使って関数呼び出しを横取りすることができて、8.2.4バージョンで防止された CVE-2007-2138 の脆弱性と同様の方法で、権限拡大を狙うことが可能でした。
</p>
<p>
一時スキーマとは一時オブジェクトのためのスキーマです。pg_temp_1 など番号を伴う名前が自動付与されますが、指定する場合には pg_temp という名前で代表させることができます。また、search_path に明示的な pg_temp の指定が無いと一時スキーマは優先して選択されます。
</p>
<p>
本修正後は、以下例の最初の型キャストは使用できず、型キャストのための処理に進む前にエラーになります（後者の 2つもエラーですが、これらは型キャスト処理が働いた結果のエラーです）。
</p>
<pre>db=# CREATE DOMAIN pg_temp.nonempty AS text CHECK (VALUE &lt;&gt; '');

db=# SELECT nonempty('');
ERROR:  function nonempty(unknown) does not exist
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

db=# SELECT pg_temp.nonempty('');
ERROR:  value for domain nonempty violates check constraint "nonempty_check"

db=# SELECT ''::nonempty;
ERROR:  value for domain nonempty violates check constraint "nonempty_check"
</pre>
<li>型を跨る比較を要するハッシュ化された副プランの実行が修正されました。(CVE-2019-10209) (Tom Lane, Andreas Seltenreich) (11)</li>
<p>
ハッシュ化された副プランは、ハッシュ要素を比較するために外側の問い合わせの元の比較演算子を使用していました。その演算子が型を跨る場合は、全てのハッシュ要素が副問い合わせの出力型になるので、これは誤りでした。PostgreSQL本体に含まれるハッシュ可能な型を跨る演算子に対して、64bitマシンでは、この誤りはほぼ無害です。しかし、32bitマシンでは、クラッシュやサーバメモリの不当なデータ露出になる可能性があります。
</p>
<p>
以下の問い合わせは = 演算子が text型と副問い合わせからの name型（外側と異なるデータ型）との間で適用され、副問い合わせ結果が「hashed SubPlan 1」として扱われるので、問い合わせの形状としては本問題に該当します。
</p>
<pre>explain (verbose)
  SELECT 'foo'::text IN (SELECT 'bar'::name UNION ALL SELECT 'bar'::name);
</pre>
<p>
拡張モジュールが、より大きなリスクをもたらすハッシュ可能な型を跨る演算子を提供しているかもしれません。
</p>
<li>複数列の型を1つのコマンドで変更するとき、ALTER TABLE ... ALTER COLUMN TYPE が失敗する動作が修正されました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これは一つ前のマイナーリリースで混入した障害です。変更された列のインデックスが適切に処理されていませんでした。
</p>
<p>
インデックスを持つ列をいくつかデータ型変更する ALTER TABLE に対して、以下のエラーになる動作が報告されました。
</p>
<pre>ERROR:  relation "《インデックス名》" already exists
</pre>
<li>子パーティションに保留中のトリガイベントがある場合には、パーティションテーブルのトリガを削除できないようになりました。 (Álvaro Herrera) (11)</li>
<p>
特にトリガで実現されている外部キー制約で該当します。
</p>
<p>
本修正前には、トランザクションのコミット時に処理すべきトリガが削除されてしまったことで COMMIT時にエラーが生じる可能性がありました。
</p>
<pre>（例）
db=# CREATE TABLE t4_1(f1 int primary key);
db=# CREATE TABLE t4_2(f1 int REFERENCES t4_1 DEFERRABLE INITIALLY DEFERRED)
       PARTITION BY RANGE (f1);
db=# CREATE TABLE t4_2_p1 PARTITION OF t4_2 FOR VALUES FROM (0) TO (10);
db=# INSERT INTO t4_1 VALUES (1);
db=# BEGIN;
db=# INSERT INTO t4_2 VALUES (1);
db=# ALTER TABLE t4_2 DROP CONSTRAINT t4_2_f1_fkey;
（修正後はここで以下のようなエラーが生じる）
ERROR:  cannot ALTER TABLE "t4_2" because it has pending trigger events
db=# COMMIT;
（修正前はここで以下のようなエラーが生じる）
ERROR:  relation 16123 has no triggers
</pre>
<li>パーティションテーブルから属するパーティションにトリガ定義をコピーする際に、ユーザ指定のトリガ引数が含まれるようになりました。 (Patrick McHardy) (11)</li>
<p>
本修正前は「CREATE TRIGGER ... EXECUTE FUNCTION my_trigger_func('my params', 123);」などとして付与した引数が欠落してコピーされていました。
</p>
<li>パーティションのキー列の削除を防止する依存性が導入されました。 (Tom Lane) (11)(10)</li>
<p>
ALTER TABLE ... DROP COLUMN はパーティションキーである列の削除を拒絶します。しかしながら、間接的な削除（キー列のデータ型をカスケード削除する場合など）では、このようなチェックが働かず、キー列の削除を許していました。この結果、パーティションテーブルが壊れて、アクセスも削除もできなくなるおそれがありました。
</p>
<p>
本修正は、キー列の削除を要するカスケード削除の際にはパーティションテーブル全体を削除するという要素を pg_depend に追加します。これはパーティションテーブルが作られるときに追加されます。したがって、バージョンアップ前に作られた既存パーティションテーブルでは、キー列のみ削除されてしまうリスクが残ります。
</p>
<p>
この問題は組み込みのデータ型のパーティションキー列では発生しません。したがって、大部分のユーザには無害であると考えられます。
</p>
<li>パーティションテーブルとそのデフォルトパーティションの間で列番号が確実に正しく対応付けされるようにしました。 (Amit Langote) (11)</li>
<p>
デフォルトパーティションでのみ一部の列を削除してあるなど、列が1対1対応でない場合に誤動作することがありました。
</p>
<p>
その後の有効なパーティションテーブルに対する操作（パーティション追加など）で、以下のようなエラーが生じる可能性がありました。
</p>
<pre>ERROR:  attribute 4 of type t7_partition_1 has been dropped
</pre>
<li>インデックスをパーティションテーブル全体に作成するときに、外部テーブルである所属パーティションを無視するようになりました。 (Álvaro Herrera) (11)</li>
<p>
これまではインデックスを作成しようとしたり、インデックスのあるパーティションテーブルに外部テーブルをアタッチするときに、以下のようなエラーが発生していました。
</p>
<pre>ERROR: cannot create index on foreign table "t8_parted"
</pre>
<p>
これからは外部テーブルのパーティションについては単にインデックスが作られない動作になります。ただし、ユニークインデックスである場合には例えば以下のようなエラーになります。
</p>
<pre>ERROR: cannot create unique index on partitioned table "t8_parted"
</pre>
<li>より多くの場合にパーティションテーブルのデフォルトパーティションが検索時にスキャン対象から除外できるようになりました。 (Yuzuko Hosoya) (11)</li>
<li>RANGEパーティションで boolean型の複数パーティションキー列があるときに検索でのパーティション除外に失敗する可能性があり、修正されました。 (David Rowley) (11)</li>
<li>対象のテーブルが継承親テーブルであるときには、GROUP BY列を最適化で消し去らないようになりました。 (David Rowley) (11)(10)(9.6)</li>
<p>
通常、テーブルの主キー列が GROUP BY に含まれる場合は他のグループ化列を安全に除去することができます。主キー列でグループを特定できるからです。しかし、継承テーブルを読む場合には、親子テーブル間、子テーブル間をまたがるユニーク性は保証されないため、この最適化は使えません。
</p>
<p>
以下の誤動作が報告されました。最後の SELECT は 2行が返るのが正しい動作です。実行プランで c1列がグループ化対象から外れてしまっていました。
</p>
<pre>db1=# CREATE TABLE t11  (c0 INT PRIMARY KEY, c1 INT);
db1=# CREATE TABLE t11c (c0 INT) INHERITS (t11);
db1=# INSERT INTO t11  (c0, c1) VALUES (0, 0);
db1=# INSERT INTO t11c (c0, c1) VALUES (0, 1);
db1=# SELECT c0, c1 FROM t11 GROUP BY c0, c1;
 c0 | c1
----+----
  0 |  0
(1 row)
</pre>
<li>semi-join問い合わせに対する並列ハッシュの誤使用が回避されました。 (Thomas Munro) (11)</li>
<p>
この障害により、一部の EXISTS問い合わせからの結果行が重複し、誤った結果が返ります。
</p>
<li>GROUPING SETSを伴う一部の問い合わせに対して、不要なソート処理の使用が回避されました。 (Andrew Gierth, Richard Guo) (11)(10)(9.6)(9.5)</li>
<p>
修正前も、処理が非効率にはなりますが、問い合わせ結果は正しいです。
</p>
<li>プランナがインデックス端点を調べるのに失敗する可能性があり、修正されました。 (Tom Lane) (11)</li>
<p>
PostgreSQLのプランナはインデックスを使って値の最大値、最小値を調べる動作をすることがあります。
</p>
<p>
プランナが列の最小値や最大値を知るために最近に作られたインデックスを使うとき、最近に無効になった実際には端点値を含まないタプルを誤って選択してしまう可能性がありました。
</p>
<p>
誤選択したタプルには NULL が入っているかもしれず、最悪の場合は、以下のエラーになります。
</p>
<pre>ERROR: found unexpected null value in index ...
</pre>
<p>本障害でよくある挙動は、誤った値が使われてプラン作成におけるデータ推測の品質が劣化することです。</p>
<li>EvalPlanQual の再チェックにおいて、トリガの遷移テーブルにアクセスするのに失敗していたものが修正されました。 (Alex Aktsipetrov) (11)(10)</li>
<p>
遷移テーブルを使った処理で以下のエラーが出るケースが報告されました。</p>
<pre>ERROR:  executor could not find named tuplestore "《NEW遷移テーブル》"
</pre>
<p>
EvalPlanQual処理は、READ COMMITTEDトランザクション隔離モードでの行の更新で使われる内部的な仕組みです。
</p>
<li>外部キー制約を再構築するときの複数列の外部キーの誤った処理が修正されました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
外部キーの全列が同じデータ型でない場合に、ALTER TABLEが外部キーの再検証が必要かどうかの判断を誤る可能性がありました。この判断の誤りは常に保守的な方向で、再検証が不要なものを必要と判断すると見られます。したがって、不要な処理による性能上のバグと言えます。
</p>
<li>継承ツリーに対して拡張統計情報を作らないようになりました。 (Tomas Vondra) (11)(10)</li>
<p>
これにより、ANALYZE の際に以下のエラーが出るのを回避します。
</p>
<pre>ERROR:  tuple already updated by self
</pre>
<li>タプルロックを格上げする際の偽性のデッドロックエラーが回避されました。 (Oleksii Kliukin) (11)(10)(9.6)</li>
<p>
複数のトランザクションがトランザクションT1 が行ロックを解放するのを待っていて、T1 がそのロックレベルを格上げするとき、T1終了時に待っているトランザクションの間で偽性の（実際にはデッドロックではない）デッドロックが報告されました。
</p>
<p>
ここでのロックレベルの格上げとは、「SELECT ... FOR KEY SHARE」 の行ロックを取得している行に対して、次に「UPDATE ...」を行う場合などを指します。
</p>
<li>複数のパラレルワーカプロセスに関わるデッドロック解決の失敗が修正されました。 (Rui Hai Jiang) (11)(10)(9.6)</li>
<p>
本障害に該当した場合、デッドロック状態がデッドロックエラーにならず、問い合わせがキャンセルされるまで処理がブロックされてしまいます。
</p>
<p>
本障害が人工的な問い合わせ以外で発生するのかは明らかではありません。通常パラレルワーカがリーダプロセスで取得済みのロック以外を必要とすることは無いため、実際には問題はほぼ起きないと考えられます。
</p>
<li>端点に infinity や -infinity を持つ日付範囲の誤った標準化が防止されました。 (Laurenz Albe) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
範囲データ型は、ある値以上である値より小さいという半開区間になるように境界値を標準化させます。これを誤って無限値（infinity、-infinity）に対しても同様に試みていました。無限値の場合には干渉しないようになりました。
</p>
<p>
修正前は以下のような奇妙な振る舞いが生じていました。
</p>
<pre>db1=# SELECT '[-infinity,infinity]'::daterange @&gt; '-infinity'::date "include?";
 include?
----------
 t
(1 row)

db1=# SELECT '[-infinity,infinity]'::daterange @&gt; 'infinity'::date "include?";
 include?
----------
 f
(1 row)

db1=# SELECT '[-infinity,infinity]'::daterange;
      daterange
----------------------
 [-infinity,infinity)
(1 row)
</pre>
<li>大きい money型の値を numeric型に変換するときの端数の損失が修正されました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
money型の最大値（あるいは負の最小値）に近い値で以下のように不正確な変換が生じる可能性がありました。
</p>
<pre>db=# select '-92233720368547758.07'::money, '-92233720368547758.07'::money::numeric(30,2);
           money            |       numeric
----------------------------+----------------------
 $92,233,720,368,547,758.07 | 92233720368547758.00
(1 row)
</pre>
<li>BTREE_META_CLEANUP の WALレコードの表示が修正されました。 (Michael Paquier) (11)</li>
<p>
これは pg_waldump のクラッシュをひき起こしました。
</p>
<li>version-2 の Btreeメタページに対する誤った処理によるアサート失敗が防止されました。 (Peter Geoghegan) (11)</li>
<p>
10以前のバージョンで作った Btreeインデックスがあって、それを pg_upgrade でバージョンアップした後のアクセスで問題が生じました。11 でも修正されていますが、実際にアサート失敗が起きるのは 12 の betaバージョンです。
</p>
<li>MIPS r6 で動作するように、MIPS CPUむけのスピンロックのアセンブラコードが修正されました。 (YunQiang Su) (11)(10)(9.6)(9.5)(9.4)</li>
<li>PL/pgSQL関数から返されるレコードまたは ROW値が複合型として型付けされるようになりました。 (Tom Lane) (11)</li>
<p>
これによって結果がテーブルに直接格納された場合の問題が回避されます。これまでは以下の処理でエラーが発生していました。
</p>
<pre>db=# CREATE TYPE two_int8s AS (q1 int8, q2 int8);
db=# CREATE FUNCTION compresult(int8) RETURNS two_int8s LANGUAGE plpgsql AS
       $$ DECLARE r record; BEGIN r := ROW($1,$1); RETURN r; END $$;
db=# CREATE TABLE two_int8s_tab (f1 two_int8s);
db=# INSERT INTO two_int8s_tab VALUES (compresult(42));
db=# SELECT f1 FROM two_int8s_tab;
   f1
---------
 (42,42)
(1 row)

(再接続後に実行)
db=# SELECT f1 FROM two_int8s_tab;
ERROR:  record type has not been registered
</pre>
<li>libpqライブラリで接続サービスファイル内の復帰コード(<br />
)が無視されるようになりました。 (Tom Lane, Michael Paquier) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
ごくまれな場合に、Windows形式の改行コードを含むサービスファイルが誤って解析され、接続エラーになっていました。
</p>
<li>psqlコマンドで、SET variable = の後について、variable が既知のパラメータ名でない場合にはタブ補完を行わないようになりました。 (Tom Lane) (11)(10)(9.6)</li>
<li>psql の d コマンドの軽微なメモリリークが修正されました。 (Tom Lane) (11)(10)</li>
<li>pg_dump コマンドが修正され、カスタム演算子クラスが正しい順序でダンプされるようになりました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
ユーザ定義 opclass がユーザ定義範囲型のサブタイプ opclass である場合、関連するオブジェクトが誤った順序でダンプされ、リストアできないダンプが生成されていました。
</p>
<p>
opclass の依存関係を処理する潜在的なエラーはほかのケースでも発生する可能性がありますが、これは唯一知られているケースです。
</p>
<li>-Rオプションの使用時に発生しうる pgbenchコマンドのハングアップが修正されました。 (Fabien Coelho) (11)(10)</li>
<li>contrib/amcheck のインデックス検証の信頼性が改善されました。 (Peter Geoghegan) (11)</li>
<li>contrib/jsonb_plperl で Perl の undef値の処理が修正されました。 (Ivan Panchenko) (11)</li>
<p>
NULL を Perl の undef値として扱わせて、それを jsonb に変換する場合に以下エラーが出るケースが報告されました。
</p>
<pre>ERROR:  cannot transform this Perl type to jsonb
</pre>
<li>contrib/passwordcheck が修正され、check_password_hook がほかのユーザと共存できるようになりました。 (Michael Paquier) (11)(10)(9.6)(9.5)(9.4)</li>
<li>contrib/sepgsql のテストが修正され、最近の SELinuxリリースでも動作するようになりました。 (Mike Palmiotto) (11)(10)(9.6)(9.5)(9.4)</li>
<li>src/test/kerberos および src/test/ldap のリグレッションテストの安定性が改善されました。 (Thomas Munro, Tom Lane) (11)</li>
<li>src/test/recovery のリグレッションテストの安定性が改善されました。 (Michael Paquier) (11)(10)(9.6)</li>
<li>pg_upgradeコマンドのテストスクリプトからの標準エラーへの出力が削減されました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<li>pgbenchコマンドのリグレッションテストがWindows でも動作するように修正されました。 (Fabien Coelho) (11)</li>
<li>ビルドディレクトリがルート以外の msysマウントポイントにある場合でも、TAP テストが msys の Perl で動作するように修正されました。 (Noah Misch) (11)(10)(9.6)</li>
<li>Microsoft Visual Studio 2019 でのビルドに対応しました。 (Haribabu Kommi) (11)(10)(9.6)(9.5)(9.4)</li>
<li>Visual Studioビルドでは、環境変数 WindowsSDKVersion が設定されている場合、それを優先するようになりました。 (Peifeng Qiu) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これにより、VS 2017 と SDK v10 の組み合わせでビルドする際にSDK v8.1 が無いとビルドに失敗する問題が回避されます。
</p>
<li>Visual Studio ビルドで OpenSSL 1.1.0 以降に対応しました。 (Juan José Santamaría Flecha, Michael Paquier) (11)(10)(9.6)(9.5)(9.4)</li>
<li>GNU 以外の makeコマンドが最上位のディレクトリで呼び出されたときにmakeコマンドのオプションが gmakeコマンドに渡されるようになりました。 (Thomas Munro) (11)(10)(9.6)(9.5)</li>
<li>initdbコマンドの実行中に TimeZoneパラメータとして localtime または posixrules が選択されないようになりました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
場合によっては initdbコマンドは実際のゾーン名より優先して、これらの人工的なゾーン名のいずれかを選択していました。
</p>
<p>
これらの 2 つよりも C ライブラリのタイムゾーンの動作に一致するほうが優先されるようになります。
</p>
<li>pg_timezone_namesビューが調整され、短い省略形をもつ場合に限って Factoryタイムゾーンを表示するようなりました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
歴史的に IANA では、この人工的なゾーンに「Local time zone must be set--see zic manual page」のような省略形を設定します。tzdbデータベースの最新バージョンでは代わりに -00 が表示されますが、一部のプラットフォームでは何らか歴史的なフレーズを表示するためにデータを変更します。
</p>
<p>
最新の省略形が使用される場合に限ってこのタイムゾーンを表示することで、非常に長い文字列が abbrev列に出力されるのが防止されました。
</p>
<li>タイムゾーンライブラリのコピーが IANA の tzcode release 2019b と同期されました。 (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これによって zicコマンドに新しい -b slim オプションが追加され、インストールされたゾーンファイルのサイズを削減できます。現在は使用されていませんが、将来的には有効になる可能性があります。
</p>
<li>タイムゾーンデータファイルが tzdata release 2019b に更新されて、ブラジルでの夏時間規則の変更に加えて、香港、イタリア、およびパレスチナの歴史的な修正が適用されました。 (11)(10)(9.6)(9.5)(9.4)</li>
</ol>

<div>
<a href="https://www.sraoss.co.jp/prod_serv/support/pgsql-mainte/?utm_source=sraoss-techblog&utm_medium=referral&utm_campaign=under-article-pgsql" rel="noopener" style="color:initial;" target="_blank" class="no-ext"></p>
<div style="background-color:#DAEFF6; padding:20px; border-radius:8px; text-align:center;">
SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。<br />
詳しくは<strong style="color:#2581c4;">弊社ホームページ</strong>をご覧ください。
</div>
<p></a>
</div>

]]></content:encoded>
					
		
		
			</item>
	</channel>
</rss>
