<?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.5 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql-9-5/feed/index.xml" rel="self" type="application/rss+xml" />
	<link>https://www.sraoss.co.jp/tech-blog/</link>
	<description>OSS専門の技術ブログ。PostgreSQL、Zabbixを中心に10種類以上のOSSの解説、アップデート情報、運用ヒントを提供。</description>
	<lastBuildDate>Mon, 09 Nov 2026 03:35:26 +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.5 &#8211; SRA OSS Tech Blog</title>
	<link>https://www.sraoss.co.jp/tech-blog/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>PostgreSQL 9.5.25 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-5-25/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Tue, 02 Mar 2021 08:30:14 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.5]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=6753</guid>

					<description><![CDATA[このリリースは 9.5.24 からの修正リリース（2021年2月11日リリース）です。 本リリースが9.5.Xの最終リリースとなる見通しです。 9.5.X からのアップデートではダンプ、リストアは不要です。 しかしながら ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.5.24 からの修正リリース（2021年2月11日リリース）です。<br />
本リリースが9.5.Xの最終リリースとなる見通しです。</p>
<p><span id="more-6753"></span></p>
<p>9.5.X からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、１番、３番、４番の項目にはバージョンアップ後に実施すべき手順があります。<br />
また、9.5.20より前のバージョンからアップデートする場合には<a href="/tech-blog/pgsql/9-5-20/">9.5.20のリリース情報</a>も参照してください。</p>
<h3>PostgreSQL 9.5.24 から 9.5.25 への変更点</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>
<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.5.24 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-5-24/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Fri, 20 Nov 2020 02:00:11 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.5]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=6601</guid>

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

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

					<description><![CDATA[このリリースは 9.5.21 からの修正リリース（2020年5月14日リリース）です。9.5.x からのアップデートではダンプ、リストアは不要です。ただし、9.5.20よりも前のバージョンからアップデートする場合には、9 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.5.21 からの修正リリース（2020年5月14日リリース）です。9.5.x からのアップデートではダンプ、リストアは不要です。ただし、9.5.20よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/9-5-20/">9.5.20 のリリース情報</a>を参照してください。</p>
<p><span id="more-5928"></span></p>
<h3>PostgreSQL 9.5.21 から 9.5.22 への変更点</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.5.21 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-5-21/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Fri, 28 Feb 2020 05:01:22 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.5]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=5730</guid>

					<description><![CDATA[このリリースは 9.5.20 からの修正リリース（2020年2月13日リリース）です。9.5.x からのアップデートではダンプ、リストアは不要です。9.5.20 より前のバージョンからのアップデートの場合には、9.5.2 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.5.20 からの修正リリース（2020年2月13日リリース）です。9.5.x からのアップデートではダンプ、リストアは不要です。9.5.20 より前のバージョンからのアップデートの場合には、<a href="/tech-blog/pgsql/9-5-20/">9.5.20 のリリース情報</a>も参照してください。</p>
<p><span id="more-5730"></span></p>
<h3>PostgreSQL 9.5.20 から 9.5.21 への変更点</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.5.20 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-5-20/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Fri, 22 Nov 2019 02:31:10 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.5]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=4966</guid>

					<description><![CDATA[このリリースは 9.5.19 からの修正リリース（2019年11月14日リリース）です。 9.5.x からのアップデートではダンプ、リストアは不要です。 ただし、contrib/intarray で &lt;@ 演算子に ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.5.19 からの修正リリース（2019年11月14日リリース）です。</p>
<p>9.5.x からのアップデートではダンプ、リストアは不要です。<br />
ただし、contrib/intarray で &lt;@ 演算子に GiSTインデックスを使っている場合には、下記の 83番の項目を確認してください。<br />
9.5.13 より前のバージョンからのアップデートの場合には <a href="/tech-blog/pgsql/9-5-13/">9.5.13 のリリース情報</a>も確認してください。</p>
<p><span id="more-4966"></span></p>
<h3>PostgreSQL 9.5.19 から 9.5.20 への変更点</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.5.19 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-5-19/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Thu, 22 Aug 2019 01:01:07 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.5]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=3773</guid>

					<description><![CDATA[このリリースは 9.5.18 からの修正リリース（2019年8月8日リリース）です。 9.5.x からのアップデートではダンプ、リストアは不要です。 9.5.13 より前のバージョンからのアップデートの場合には 9.5. ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.5.18 からの修正リリース（2019年8月8日リリース）です。</p>
<p>9.5.x からのアップデートではダンプ、リストアは不要です。<br />
9.5.13 より前のバージョンからのアップデートの場合には <a href="/tech-blog/pgsql/9-5-13/">9.5.13 のリリース情報</a>も確認してください。</p>
<p><span id="more-3773"></span></p>
<h3>PostgreSQL 9.5.18 から 9.5.19 への変更点</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>
		<item>
		<title>PostgreSQL 9.5.18 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-5-18/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Thu, 04 Jul 2019 01:01:49 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.5]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=2947</guid>

					<description><![CDATA[このリリースは 9.5.17 からの修正リリース（2019年6月20日リリース）です。 9.5.x からのアップデートではダンプ、リストアは不要です。 9.5.13より前のバージョンからのアップデートの場合には 9.5. ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.5.17 からの修正リリース（2019年6月20日リリース）です。</p>
<p>9.5.x からのアップデートではダンプ、リストアは不要です。<br />
9.5.13より前のバージョンからのアップデートの場合には <a href="/tech-blog/pgsql/9-5-13/">9.5.13 のリリース情報</a>も確認してください。</p>
<p><span id="more-2947"></span></p>
<h3>PostgreSQL 9.5.17 から 9.5.18 への変更点</h3>
<p>11.4、10.9、9.6.14、9.5.18、9.4.23 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<hr />
<ol>
<li>SCRAM検証のパース処理におけるバッファオーバフロー障害が修正されました。  (Jonathan Katz, Heikki Linnakangas, Michael Paquier) (11)(10)</li>
<p>
認証を受けるユーザは誰でも、パスワードを意図的に作りこんだ値に変更することで、スタックのバッファオーバフローを起こすことができました。さらに PostgreSQLサーバをクラッシュさせることもできました。これにより PostgreSQLを実行するOSユーザで任意コードを実行できる可能性がありました。
</p>
<p>
類似のオーバフロー障害が libpq にもあり、これはよからぬサーバがクライアントをクラッシュさせたり、クライアント側OSユーザで任意コードを実行させたりできる可能性がありました。(CVE-2019-10164)
</p>
<li>実行時パーティション除外のロジックで、いくつかの誤りが修正されました。  (Tom Lane, Amit Langote, David Rowley) (11)</li>
<p>
除外に使われる比較値が（プリペアドステートメントのパラメータで）動的に決定される場合や、複数のレンジパーティション列が除外の判断に関わる場合、あるいは、STABLEな（IMMUTABLE でない）比較演算子が関わる場合に、本障害がパーティションテーブルに対する問い合わせに誤った結果をもたらすおそれがありました。
</p>
<pre>
（上記の内「複数レンジパーティション列が関与する」ときの障害動作例）
db=# CREATE TABLE t2p (a int, b int, c int) PARTITION BY RANGE (a, abs(b), c);
db=# CREATE TABLE t2p0 PARTITION OF t2p
       FOR VALUES FROM (0, 0, 0) to (0, maxvalue, maxvalue);
db=# CREATE TABLE t2p1 PARTITION OF t2p
       FOR VALUES FROM (1, 1, 1) TO (2, minvalue, minvalue);
db=# CREATE TABLE t2p2 PARTITION OF t2p
       FOR VALUES FROM (2, minvalue, minvalue) TO (3, maxvalue, maxvalue);
db=# INSERT INTO t2p VALUES (0, 1, 1), (1, 1, 1), (2, 1, 1);

（以下は 3行返るのが正しい）
db=# SELECT * FROM t2p WHERE a &lt; 3 AND abs(b) = 1;
 a | b | c
---+---+---
 1 | 1 | 1
(1 row)
</pre>
<li>新たなパーティションにトリガ定義をコピーするときにクラッシュする可能性があり、修正されました。  (Tom Lane) (11)</li>
<p>
パーティションテーブルにトリガが定義されている状態で、属するパーティションを新たに追加したときにクラッシュする動作が報告されました。
</p>
<li>テーブルが部分的な排他制約を持つ場合に、ALTER TABLE ... ALTER COLUMN TYPE ... がエラーになる動作が修正されました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<pre>
（以下のエラー発生パターンが報告されました）
db=# CREATE TABLE t4 (id int);
db=# ALTER TABLE t4 ADD EXCLUDE USING btree (id WITH =) WHERE (id IS NOT NULL);
db=# ALTER TABLE t4 ALTER COLUMN id TYPE bigint;
ERROR:  relation "t4_id_excl" already exists
</pre>
<p>
発生するエラーは以下のようにバージョンによって様々です。「ERROR: could not open relation with OID 123456」「ERROR: cache lookup failed for relation 654321」「ERROR: relation "t4_id_excl" already exists」
</p>
<li>ドメインの制約に対するコメントでCOMMENTコマンドがエラーになる動作が修正されました。  (Daniel Gustafsson, Michael Paquier) (11)(10)(9.6)(9.5)</li>
<p>
一般ユーザで実行時に以下のような奇妙なエラーが報告されました。
</p>
<pre>
db=&gt; CREATE DOMAIN ddd AS text CONSTRAINT ccc CHECK (TRUE);
db=&gt; COMMENT ON CONSTRAINT ccc ON DOMAIN ddd IS 'test';
ERROR:  type with OID 16413 does not exist
</pre>
<li>ハッシュ集約のハッシュキーのリストに重複する列があるとき、不適切なメモリ上書きの可能性があり、防止されました。  (Andrew Gierth) (11)(10)</li>
<p>
例えば、以下の形状の問い合わせで HashAggregate が生じた場合に該当する可能性があります。
</p>
<pre>
db=# CREATE TABLE t6a (v text);
db=# CREATE TABLE t6b (v1 text, v2 text);
db=# SELECT * FROM t6b WHERE (v1, v2) IN (SELECT v, v FROM t6a);
</pre>
<li>ゼロ個または複数個の引数を伴う集約関数の部分集約における、引数の誤ったNULL検査が修正されました。  (David Rowley, Kyotaro Horiguchi, Andres Freund) (11)</li>
<p>
部分集約(Partial Aggregate)は集約をパラレル実行するときに生じるプラン要素です。パラレル実行時に単一引数でない集約関数に不正な結果が返る動作が報告されました。
</p>
<li>Merge Appendプランの誤った生成が修正されました。  (Tom Lane) (11)(10)(9.6)</li>
<p>
以下のエラーが発生する可能性があります。
</p>
<pre>
ERROR:  could not find pathkey item to sort
</pre>
<p>
SELECT DISTINCT ... FROM (SELECT ... UNION ALL SELECT ...) という形状の問い合わせで発生が報告されました。
</p>
<li>重複する結合名を伴う問い合わせの誤った出力が修正されました。  (Philip Dub&eacute;) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
この誤りで、このような問い合わせを含むビューのダンプ/リストア失敗が生じます。同様に psql の d+ コマンドでも誤った出力が生じます。
</p>
<p>
以下例の「same」が重複する結合名で、このビューは正しくダンプされません。
</p>
<pre>
CREATE TABLE t9_1 (c1 int);
CREATE TABLE t9_2 (c2 int);
CREATE TABLE t9_3 (c3 int);
CREATE TABLE t9_4 (c4 int);
CREATE VIEW v9 AS
  SELECT * FROM (
    SELECT * FROM (t9_1 CROSS JOIN t9_2) same) ss,
      (t9_3 CROSS JOIN t9_4) same;
</pre>
<li>json_to_record() と json_populate_record() で、JSON文字列リテラルからJSON型出力列への変換を修正しました。  (Tom Lane) (11)(10)</li>
<p>
エスケープを要する文字を含むリテラルで誤動作が生じていました。jsonb型むけ同様の関数では正しく動作していました。
</p>
<pre>
（エラーが発生する誤動作の例）
db=# SELECT * FROM json_to_record('{"out": "{"key": 1}"}') as x(out json);
ERROR:  invalid input syntax for type json

（正しくは以下の出力）
      out       
----------------
 "{"key": 1}"
(1 row)
</pre>
<li>正規表現で {1,1} 量指定子の誤った最適化が修正されました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
このような量指定子は何もしないものとして最適化で無きものとされていました。しかし、{1,1}? と最短マッチ指定が付いた場合には、この最適化は不適切です。誤動作は副式が取り込み括弧を含むか後方参照を含む場合のみ発生します。
</p>
<pre>
（誤動作例: 最初の取り込み括弧が最短マッチであることが反映されていない）
db=# SELECT regexp_matches('AAbbbccc', '^(A*){1,1}?(.*)(c*)$');
 regexp_matches
----------------
 {AA,bbbccc,""}
(1 row)

（修正後の正しい応答）
  regexp_matches  
------------------
 {"",AAbbbccc,""}
(1 row)
</pre>
<li>ページ分割の際にINCLUDEされた列を処理して失敗するという稀な場合に、無効な空のBtreeインデックスページを書き出す動作が回避されました。  (Peter Geoghegan) (11)</li>
<p>
この無効なページは通常のインデックス操作では動作に影響ありませんが、後の VACUUM でエラーを起こす可能性があります。インデックス再構築（REINDEX）を行って復旧することができます。
</p>
<li>新たなプロセスの pg_stat_activity むけデータを初期化する際に失敗することがあり、回避されました。  (Tom Lane) (11)(10)(9.6)(9.5)</li>
<p>
SSL証明書から取り出した文字列をデータベースエンコーディングに変換する等の場合に失敗する可能性がありました。これはクリティカルセクション内で実行されるため、共有の pg_stat_activityデータに対するアクセス手順を妨げ、データベース全体のハングアップをひき起こしました。
</p>
<li>既存の共有メモリセグメントが別のpostmasterから未だ使用中かどうかを検査する際の競合状態が修正されました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
実行タイミングによっては検査をすり抜けて他のpostmasterが使用中の共有メモリを削除してしまうことがあり得ました。
</p>
<li>walreceiverのシグナルハンドラにおける安全でないコーディングが修正されました。  (Tom Lane) (11)(10)</li>
<p>
これにより、walreceiverプロセスが終了シグナル(SIGTERM)を受けたときにクラッシュまたはデッドロックするという、稀に起こりうる問題を回避します。
</p>
<li>特定データベースに接続していないプロセス(walsender等)がパラメータ検査のためにデータベースアクセスを試みる動作が回避されました。  (Vignesh C, Andres Freund) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
この誤りは「FATAL:  cannot read pg_class without having selected a database」のようなエラーをもたらしました。
</p>
<li>SSL を使っていて OpenSSL のデータバッファにちょうど 256×N バイトが含まれる場合の libpq でのハングアップが回避されました。  (David Binderman) (11)(10)(9.6)(9.5)</li>
<li>initdb でシステムタイムゾーンに対する複数の等価な名前の扱いが改善されました。  (Tom Lane, Andrew Gierth) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
initdb は /etc/localtime シンボリックリンクを調べて、シンボリックリンクが存在するなら、システムタイムゾーンに対して等価な名前の中から、それを選ぶようになりました。
</p>
<p>
これにより initdb は同一タイムゾーンが複数存在する場合にユーザーが予期するタイムゾーン名を選択します。 /etc/localtime がゾーンデータファイルへのシンボリックリンクでない場合や、タイムゾーンが TZ環境変数から決定される場合の振る舞いは変更ありません。
</p>
<p>
これとは別に、TZ も /etc/localtime もヒントとして提供されていない時、そのタイムゾーンの他のスペルよりも UTC を優先するようになりました。これにより tzdata 2019a によってもたらされた煩わしい変更を修正します。それは UCT と UTC のゾーン名を同等にするための変更で、initdb は UCT を好むようになりましたが、ほとんど誰も望んでいません。
</p>
<li>pg_dump と pg_dumpall によって発行されたデータベースとテーブルスペースに対するGRANTコマンドの順序が修正されました。  (Nathan Bossart, Michael Paquier) (11)(10)(9.6)</li>
<p>
カスケードしている GRANT が発行されている場合、それらの相互依存性に考慮しない順序で GRANTコマンドが並んでいるために、リストアが失敗する可能性がありました。
</p>
<li>pg_dump がテーブルパーティションを再作成する際、作成コマンドにCREATE TABLE ... PARTITION OF ... ではなく、CREATE TABLE の後に ALTER TABLE ... ATTACH PARTITION をするように変更されました。  (&Aacute;lvaro Herrera, David Rowley) (11)(10)</li>
<p>
これによりパーティションの列の順序が親の列から変更されている可能性があるという問題を回避します。また、親テーブルがまだリストアされていなくても、パーティションは（スタンドアロンテーブルとして）ダンプからリストア可能となりました。 ATTACH は失敗しますが、それは無視することができます。
</p>
<li>reindexdb でのエラー時に誤解を招く余計なエラー報告が修正されました。  (Julien Rouhaud) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
インデックスやスキーマを指定して実行して失敗した場合に、以下のようなデータベースに対する reindexdb に失敗したというメッセージが出力されることがありました。
</p>
<pre>
reindexdb: reindexing of database "db" failed: ....
</pre>
<li>vaccumdb で並列ジョブ実行中にエラーが発生した場合、正しい終了ステータスを確実に返すようになりました。  (Julien Rouhaud) (11)(10)(9.6)(9.5)</li>
<p>
これまで、-j を付与して並列実行させている場合、エラーが起きていてもコマンドが正常終了(0)を返すことがありました。
</p>
<li>auto_explain でパラレルクエリの時に問題が発生しないように修正されました。  (Tom Lane) (11)(10)(9.6)</li>
<p>
以前は、auto_explain で親のクエリがログに記録されていない場合であっても、パラレルワーカーが自分自身のクエリをログに記録しようとしていました。これは時々動作することもありますが紛らわしいですし、時には「ERROR:  could not find key 3 in shm TOC at 0x7f45a0334000」のようなエラーを発生させる原因となっていました。
</p>
<p>
また、サンプリングレートが 1.0 に設定されている場合ですら、必ずしもすべてのクエリーが記録されるとも限らないという、off-by-oneバグも修正されました。
</p>
<li>postgres_fdw で BEFORE ROW UPDATEトリガーによるデータ変更がある可能性を新たに考慮するようになりました。  (Shohei Mochizuki) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これまでは不必要なデータ転送を避けるために UPDATE処理で明示的に対象となったデータだけが転送対象でした。しかし外部テーブルに BEFORE ROW UPDATEトリガーが存在している場合、トリガーは対象となっていない列も変更する可能性があり、そのような場合はそれらの列の変更された値を送り損ねてしまいます。今回の変更で BEFORE ROW UPDATEトリガーが存在するときはすべての列を送信するようにします。
</p>
<li>Windows上でデータベースエンコーディングが SQL_ASCII に設定されている時にASCII 以外の文字列を記録する試みが失敗しないようになりました。  (Noah Misch) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これまでの実装では記録する文字列が必ず UTF-8 である前提となっていて、妥当なエンコードではないように見える時はエラーを投げていました。これからは変換していないバイト列を単純にログに送信します。
</p>
<p>
該当の関数は pgwin32_message_to_UTF16() で、新しい挙動は pg_do_encoding_conversion() と整合性があります。
</p>
<li>PL/pgSQLのヘッダファイル等の変数名が C++の予約語と衝突しないように変更されました。  (George Tarasov) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これまで PL/pgSQL のヘッダファイルや Cソースファイルの変数名が（new、typeid、typemod など）C++の予約語と衝突していました。
</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.5.17 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-5-17/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Mon, 20 May 2019 02:01:25 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.5]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=2389</guid>

					<description><![CDATA[このリリースは 9.5.16 からの修正リリース（2019年5月9日リリース）です。 9.5.x からのアップデートではダンプ、リストアは不要です。 9.5.13より前のバージョンからのアップデートの場合には 9.5.1 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.5.16 からの修正リリース（2019年5月9日リリース）です。</p>
<p>9.5.x からのアップデートではダンプ、リストアは不要です。<br />
9.5.13より前のバージョンからのアップデートの場合には <a href="/tech-blog/pgsql/9-5-13/">9.5.13 のリリース情報</a>も確認してください。</p>
<p><span id="more-2389"></span></p>
<h3>PostgreSQL 9.5.16 から 9.5.17 への変更点</h3>
<p>11.3、10.8、9.6.13、9.5.17、9.4.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<hr />
<ol>
<li>行単位セキュリティポリシーが、プランナの選択性見積り処理を通して、すり抜けされてしまうことがあり、防止されました。(CVE-2019-10130)  (Dean Rasheed) (11)(10)(9.6)(9.5)</li>
<p>
一部のプランナの選択性見積り処理ではプランナ統計情報(pg_statistic の 最頻値など)で見つかった値にユーザ定義演算子を適用します。そのため、実行したユーザにその列を参照する権限がなくとも、漏洩のある演算子が一部行の列データ値を露出させることができます。9.6.3、9.5.7、9.4.12、9.3.17、9.2.21 での CVE-2017-7484 セキュリティ障害の修正で同様の問題に対する対処が行われていましたが、行単位セキュリティについては対応されていませんでした。
</p>
<p>
本修正により、漏洩のある（LEAKPROOF属性が真でない）演算子は関連する行単位セキュリティ(RLS)ポリシーが無い場合に限ってプランナ統計情報に適用が許されるようになります。
</p>
<li>パーティション振り分けのエラーを報告する際に解放済みメモリへのアクセスを回避するように修正されました。(CVE-2019-10129)  (Michael Paquier) (11)</li>
<p>
この障害はクラッシュをひき起こします。また、原理的にはサーバメモリ内容を露出させる攻撃に利用できる可能性があります。なお、上記のパーティション振り分けのエラーとは以下の類です。
</p>
<pre>
db=# CREATE TABLE parted_tbl (id int, v text) PARTITION BY RANGE (id);
db=# CREATE TABLE part1 PARTITION OF parted_tbl FOR VALUES FROM (1) TO (100);
db=# INSERT INTO parted_tbl VALUES (105, 'XX');
ERROR:  no partition of relation "parted_tbl" found for row
DETAIL:  Partition key of the failing row contains (id) = (105).
</pre>
<li>パーティションテーブルに対する ALTER TABLE がインデックス再利用可能と判断した場合にシステムテーブルのデータが破損することがあり、修正されました。  (Amit Langote, Tom Lane) (11)</li>
<p>
例えば、ALTER TABLE .. ALTER COLUMN TYPE 実行時に物理テーブルの書き換えは不要と判断したケースで発生します。ALTER TABLE を行って定義情報の破損が生じたパーティションテーブルを、次に DROP したときにバックエンドプロセスがクラッシュ終了する動作が報告されました。
</p>
<li>単文のトランザクションで ON COMMIT DROP と IDENTITY列を伴う一時テーブルが作られたときにシステムテーブルのデータが破損する障害があり、修正されました。  (Peter Eisentraut) (11)(10)</li>
<p>
以下のような発生例が報告されました。
</p>
<pre>
（あるセッションで以下のように一時テーブルを作った後、）
db=# CREATE TEMP TABLE t4 (c int GENERATED BY DEFAULT AS IDENTITY)
       ON COMMIT DROP;

（別セッションで別の一時テーブルを作ろうとした際に不明なエラーが出る）
db=# CREATE TEMPORARY TABLE t4_2 (d text);
ERROR: could not open relation with OID 16345
</pre>
<li>パーティションテーブルが属するパーティション(子テーブル)以上に削除された列を含む場合に、ALTER INDEX ... ATTACH PARTITION がエラーになる動作が修正されました。  (&Aacute;lvaro Herrera) (11)</li>
<p>
これにより pg_upgrade を失敗させる可能性もあります。以下の予期せぬエラーが発生します。
</p>
<pre>
ERROR:  incorrect attribute map
</pre>
<li>パーティションの既存インデックスを、新たに作成されたパーティションインデックス（親テーブルのインデックス）にアタッチするときのエラーが修正されました。  (Amit Langote, &Aacute;lvaro Herrera) (11)</li>
<p>
この障害は、アタッチ後に実行する当該パーティションインデックスを使う DDL で以下のような予期せぬエラーを発生させます。
</p>
<pre>
ERROR:  index ... not found in partition ...
</pre>
<li>パーティション化された問い合わせ結果に対して他セッションによる更新を反映させる処理で、バックエンドプロセスのクラッシュが回避されました。  (Amit Langote) (11)(10)</li>
<p>
これは、READ COMMITTED 隔離レベルを使用していて、他のセッションが問い合わせの対象行を同時並行に更新していた場合にEPQ(EvalPlanQual)の再チェック処理で発生します。
</p>
<li>削除された属性を持つ複数階層のパーティションテーブルでの、行の振り分けが修正されました。  (Amit Langote, Michael Paquier) (11)</li>
<p>
パーティションテーブルに列削除が行われていた場合に INSERT 実行に対して、以下の予期せぬエラーが発生する場合がありました。
</p>
<pre>
ERROR: cannot extract attribute from empty tuple slot SQL state: XX000
</pre>
<li>外部キー制約の初期検査の slow-path処理がパーティションテーブルに適用されるときの失敗が修正されました。  (Hadi Moshayedi, Tom Lane, Andres Freund) (11)</li>
<p>
（権限の問題などで）fast-path処理が使えない場合という、一般的でない場合以外では、この問題は顕在化しません。fast-path、slow-path は検査処理実装の内部的な区別です。前者が使えない場合に後者が使われます。
</p>
<p>
以下のようなエラー発生が報告されました。
</p>
<pre>
db=# CREATE ROLE test_role WITH LOGIN;
db=# CREATE TABLE t9_ref(a int PRIMARY KEY);
db=# GRANT REFERENCES ON t9_ref TO test_role;
db=# SET ROLE test_role;
db=&gt; CREATE TABLE t9(a int, b int) PARTITION BY LIST (a);
db=&gt; ALTER TABLE t9 ADD CONSTRAINT t9_b_key
        FOREIGN KEY (b) REFERENCES t9_ref(a);
ERROR:  could not open file "base/16432/49876": No such file or directory
</pre>
<li>継承ツリーやパーティションテーブルの全てのテーブルが除外されうるUPADTE や DELETE の振る舞いが修正されました。  (Amit Langote, Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
このような場合、RETURNING句があっても問い合わせが正しい列セットを報告せず、文レベルトリガがあっても実行されませんでした。
</p>
<pre>
（障害動作例: WHERE false の場合の RETURNING句の応答は列が無く不正）
db=# CREATE TABLE t10 (a int, b int);
db=# CREATE TABLE t10c () inherits (t10);
db=# INSERT INTO t10c VALUES (1,2);
db=# UPDATE t10 SET a = a + 1 WHERE false RETURNING b, a;
--
(0 rows)
UPDATE 0

db1=# UPDATE t10 SET a = a + 1 WHERE true RETURNING b, a;
 b | a
---+---
 2 | 2
(1 row)
UPDATE 1
</pre>
<li>constraint_exclusion = on でパーティションに直接アクセスするとき、除外のための CHECK制約と同様に各パーティションのパーティション制約を使用するようになりました。  (Amit Langote, Tom Lane) (11)</li>
<p>
この変更は 10.xバージョンの振る舞いに戻したことになります。
</p>
<pre>
db=# CREATE TABLE t11p (a int) PARTITION BY LIST (a);
db=# CREATE TABLE t11c PARTITION OF t11p FOR VALUES IN (1);
db=# SET constraint_exclusion TO on;
db=# EXPLAIN SELECT * FROM t11c WHERE a = 2;
（修正前の結果、範囲外の値でもテーブルスキャンが発生）
                     QUERY PLAN
----------------------------------------------------
 Seq Scan on t11c (cost=0.00..41.88 rows=13 width=4)
   Filter: (a = 2)
(2 rows)

（本来期待される結果）
                QUERY PLAN
------------------------------------------
 Result  (cost=0.00..0.00 rows=0 width=4)
   One-Time Filter: false
(2 rows)
</pre>
<li>トランザクションコミットをまたがるようにカーソル問い合わせを永続化しようとしてエラーが生じたときのクラッシュが回避されました。  (Tom Lane) (11)</li>
<p>
プロシージャがオープンされた明示的あるいは暗黙的なカーソル（PL/pgSQLのFORループ問い合わせなど）を持つときにコミットしようとした場合、カーソルはコミット前に完全に実行され結果を保存して以降で利用可能にします。このような処理の中でエラーが生じた場合にバックエンドプロセスのクラッシュが起こっていました。
</p>
<li>ロジカルレプリケーションにおける FOR ALL TABLES指定のパブリケーションが存在するときに、一時テーブルとUNLOGGEDテーブルの更新に対する不正なエラー発行が修正されました。  (Peter Eisentraut) (11)(10)</li>
<p>
このようなテーブルはパブリケーション用には無視されるべきでしたが、一部コードでそうなっていませんでした。
</p>
<li>更新可能ビューに複数行を挿入する INSERT ... VALUESコマンドでの明示的なデフォルト要素の処理が修正されました。  (Amit Langote, Dean Rasheed) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
以下例のように複数行を同時に挿入した場合、ビューにデフォルト値が無い列で元テーブルのデフォルト値ではなく NULL が使われてしまいます。
</p>
<pre>
（障害動作発生例: a=14 の行と a=15,16 の行で振る舞いが違う）
db=# CREATE TABLE t14 (a int, b text default 'Table default',
                       c text default 'Table default', d text, e text);
db=# CREATE VIEW v14 AS SELECT * FROM t14
db=# ALTER VIEW v14 ALTER b SET DEFAULT 'View default';
db=# ALTER VIEW v14 ALTER d SET DEFAULT 'View default';
db=# INSERT INTO v14 VALUES (14, default, default, default, default);
db=# INSERT INTO v14 VALUES (15, default, default, default, default),
                            (16, default, default, default, default);
db=# SELECT * FROM t14;
 a  |      b       |       c       |      d       | e
----+--------------+---------------+--------------+---
 14 | View default | Table default | View default |
 15 | View default |               | View default |
 16 | View default |               | View default |
(3 rows)
</pre>
<li>CREATE VIEW がゼロ列ビューを作れるように修正されました。  (Ashutosh Sharma) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これによりゼロ列テーブルが作成可能であることと一貫性を持ち、テーブルをビューで置き換える際に失敗するケースを回避できます。
</p>
<pre>
db=# CREATE TABLE t15 (id int primary key, v text);
db=# CREATE TABLE t15_0 ();
db=# CREATE VIEW v15 AS SELECT FROM t15;
db=# CREATE VIEW v15_0 AS SELECT * FROM t15_0;
（修正前バージョンでは上記両CREATE VIEVで以下のエラーが出ました）
ERROR:  view must have at least one column
</pre>
<li>欠けていた CREATE TABLE IF NOT EXISTS ... AS EXECUTE ... 構文が追加されました。  (Andreas Karlsson) (11)(10)(9.6)(9.5)</li>
<p>
AS の後に問い合わせにプリペアド文を実行する EXECUTE文を記述することは可能であるべきでしたが対応していませんでした。
</p>
<li>行単位セキュリティポリシーの式に現れる副問い合わせが、確実に正しいユーザ権限で実行されるようになりました。  (Dean Rasheed) (11)(10)(9.6)(9.5)</li>
<p>
これまで、行単位セキュリティ(RLS)ポリシーを持つテーブルがビューを通してアクセスされる場合に、セキュリティ検査がビューを呼び出したユーザで行われ、ビュー所有者ユーザで行われませんでした。後者が本来の正しい動作です。
</p>
<li>SQL:2006 以降の要件に基づき、xmloption = content が設定されているとき、xml型の有効な値としてXMLドキュメントを受け入れるようになりました。  (Chapman Flack) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これまでは PostgreSQL は SQL:2003 の定義に従っていて、このような場合にはデータを受け入れませんでした。しかし、ダンプ/リストアで全ての有効なXMLデータを受け入れる xmloption の設定値が無いという重大な問題が問題が生じることから、SQL:2006 の定義に変更されました。
</p>
<p>
加えて、確実にダンプ/リストアできるように pg_dump が SET xmloption = contentを出力するようになりました。
</p>
<li>サーバ起動時の既存共有メモリセグメントが未だ使われているかどうかの検査が改善されました。  (Noah Misch) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
PostgreSQLのマスタプロセス(postmaster)は、たとえ postmaster.pid ファイルが削除されていても、以前の postmasterから生じた実行中プロセスが無いかを調べるようになりました。
</p>
<p>
これにより PostgreSQL二重起動によるデータ破損を予防します。
</p>
<li>BtreeインデックスのVACUUM で、起こりうるゼロ除算が回避されました。  (Piotr Stefaniak, Alexander Korotkov) (11)</li>
<p>
これは vacuum_cleanup_index_scale_factor 設定値に基づいてインデックスのクリーンアップが必要かどうかについて不正確な判断をひき起こします。
</p>
<li>パラレルワーカのトランザクションを別々のトランザクションと数えないように修正されました。  (Haribabu Kommi) (11)(10)(9.6)</li>
<p>
パラレル問い合わせ実行があるときに、実行時統計情報のトランザクション数が本来より多く計数されていました。
</p>
<li>GINインデックスのWALレコードにおける非互換性が修正されました。  (Alexander Korotkov) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
前回のマイナーリリースには後方互換性に問題がありました。ストリーミングレプリケーション等で更に以前のマイナーバージョンが生成したWAL を適用する場合にロック処理の問題からハングアップする動作が報告されました。
</p>
<p>
本修正で WALレコードを適用する際に、前マイナーリリースの修正があるWALレコードも、無いレコードも両方読めるように修正されました。
</p>
<li>レプリケーション接続で SHOWコマンドを実行する時に起こりうるwal senderプロセスのクラッシュが修正されました。  (Michael Paquier) (11)(10)</li>
<li>ポータルから少しずつ行を取得するときのバックエンドプロセスのメモリリークが回避されました。  (Tom Lane) (11)</li>
<p>
特に JDBCで問い合わせ結果を1行ずつ取得する場合に顕在化します。
</p>
<li>パーティションのリレーションキャッシュ項目が再作成されるときのメモリリークが回避されました。  (Amit Langote, Tom Lane) (11)(10)</li>
<p>
このメモリリークはセッション内で継続します。
</p>
<li>fsync や sync_file_range を呼ぶときに、適切な箇所において、INVAL および ENOSYS のエラーに寛容になりました。  (Thomas Munro, James Sewell) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
ファイル同期に失敗が生じたなら PANIC とする前回リリースでの変更は、失敗が想定できて本質的に操作がサポートされないことによる場合については、過度に偏執的でした。
</p>
<p>
例えば Windows Subsystem for Linux において sync_file_range がサポートされないために PANIC が起きていました。
</p>
<li>autovacuum の pg_stat_activity 表示で、BRIN の要約操作中に正しいリレーション名を報告するようになりました。  (&Aacute;lvaro Herrera) (11)(10)</li>
<p>
以前は誤ってデータベース名が報告されていました。
</p>
<li>GEQO が有効なときにパーティションの関する結合プランを作成しようとしたときのバックエンドプロセスのクラッシュが回避されました。  (Tom Lane) (11)</li>
<li>プランナで FULL外部結合からのラテラル参照があるときに「ERROR:  failed to build any N-way joins」エラーが発生していたものが修正されました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<pre>
（エラー発生例）
db=# SELECT * FROM (VALUES (1),(2)) v1(r1)
       LEFT JOIN LATERAL (
         SELECT * FROM generate_series(1, v1.r1) AS gs1
           LEFT JOIN LATERAL (
             SELECT * FROM generate_series(1, gs1) AS gs2
               LEFT JOIN generate_series(1, gs2) AS gs3 ON TRUE
           ) AS ss1 ON TRUE
           FULL JOIN generate_series(1, v1.r1) AS gs4 ON FALSE
       ) AS ss0 ON TRUE;
ERROR:  failed to build any 3-way joins
</pre>
<li>複数行を返す関数を空と推定されるリレーションに適用する問い合わせに対する誤ったプラン作成が修正されました。  (Tom Lane, Julien Rouhaud) (11)(10)</li>
<p>
この障害により、10.x バージョンでは僅かに非効率なプランが生成されるだけですが、11.x バージョンでは「ERROR:  set-valued function called in context that cannot accept a set 」エラーをひき起こす可能性があります。
</p>
<li>漏洩のある演算子で pg_statistic のデータを参照させる際のルールを強制するときに、適切なユーザ権限を検査するようになりました。  (Dean Rasheed) (11)(10)(9.6)(9.5)(9.4)</li>
<p>元となるテーブルにビューを通してアクセスするとき、漏洩のある演算子をテーブルの統計データに適用して良いかの判断に、問い合わせを実行するユーザの権限ではなく、ビュー所有者の権限を考慮するようになりました。これにより、プランナのどのデータが可視かのルールをエグゼキュータのルールと一致させて、劣ったプランを回避します。
</p>
<li>グルーピングをする問い合わせでプランナの並列安全性の検査が修正されました。  (Etsuro Fujita) (11)</li>
<p>
これまでは、並列化されている可能性のある対象リストを評価する動作が無いかもしれませんでした。この問題によりプランの劣化が発生していました。
</p>
<li>プランナのユニークインデックスのロジックにおいて、INCLUDEで含められたインデックス列の誤った処理が修正されました。  (Tom Lane) (11)</li>
<p>
本障害により、含められた列を持つユニークインデックスが問い合わせ結果の唯一性を保証することをプランナが認識しなくなる可能性があり、プランの劣化がもたらされました。
</p>
<li>配列の型キャスト式に対する誤った STRICT の検査が修正されました。  (Tom Lane) (11)</li>
<p>
以下例のように STRICT を指定した SQL関数に NULL を渡しても、応答が NULL にならない動作が発生していました。
</p>
<pre>
db=# CREATE TABLE t34 (c1 int);
db=# INSERT INTO t34 VALUES (1), (NULL);
db=# CREATE FUNCTION f34 (int) RETURNS int[] LANGUAGE sql AS 
     $$ SELECT array[0, $1]::bigint[]::int[] $$ STRICT;
db=# SELECT f34(c1) FROM t34;
（修正前の応答）
   f34
----------
 {0,1}
 {0,NULL}
(2 rows)

（正しい応答、2番目は NULL が返る）
  f34
-------
 {0,1}

(2 rows)
</pre>
<li>多数のイコール条件と多数の潜在的に関連のある外部キー制約があるときのプラン作成が高速化されました。  (David Rowley) (11)(10)(9.6)</li>
<li>多数のテーブルを作成したトランザクションをロールバックするときに、テーブル数に対して O(N^2)オーダで処理を要する性能問題が回避されました。  (Tomas Vondra) (11)(10)(9.6)(9.5)(9.4)</li>
<li>動的共有メモリの割り当てで、稀な場合におきるバックエンドプロセスのクラッシュが修正されました。  (Thomas Munro, Robert Haas) (11)(10)</li>
<li>動的共有メモリの管理での競合状態を修正しました。  (Thomas Munro) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これにより「ERROR:  dsa_area could not attach to segment」や「ERROR:  cannot unpin a segment that is not pinned」のエラーが生じる可能性がありました。
</p>
<li>ホットスタンバイのPostgreSQLマスタプロセス(postmaster)が、スマートシャットダウン要求を受け取った後でシャットダウンに失敗する可能性がある競合状態が修正されました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<li>pg_identify_object_as_address()に不正な入力が与えられたとき、クラッシュを起こす可能性があり、修正されました。 (&Aacute;lvaro Herrera) (11)(10)(9.6)(9.5)</li>
<p>pg_identify_object_as_address() はシステム情報を取得するSQL関数の一つです。</p>
<li>txid_status() でトランザクション失敗の状態にアクセスできない可能性があり、修正されました。  (Thomas Munro) (11)(10)</li>
<p>
以前は未来のトランザクションの状態を取得し続けると、最終的に以下のようなエラーが発生していました。
</p>
<pre>
=# SELECT txid_status(txid_current() + 1);
ERROR:  could not access status of transaction 32768
DETAIL:  Could not read from file "pg_xact/0000" at offset 8192: No error: 0.
</pre>
<li>OpenSSLライブラリのバージョンが混在した状態でSCRAM認証を使用しようとしたときの認証失敗が修正されました。  (Michael Paquier, Peter Eisentraut) (11)</li>
<p>
サーバが OpenSSL 1.0.2 以降を使用しているときに libpq がOpenSSL 1.0.1 以前を使用していると、どの SASL機構を使用するかのネゴシエーションが失敗し、「ERROR:  channel binding not supported by this build」という分かりにくいエラーメッセージが発生していました。
</p>
<li>暗号化された SCRAM-SHA-256 および MD5 パスワードの検証が強化されました。  (Jonathan Katz) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
一致する先頭文字をもつパスワード文字列が SCRAM-SHA-256 または MD5形式に正しくハッシュ化されたものと間違われる可能性がありました。
</p>
<p>
SCRAM-SHA-256形式では先頭が SCRAM-SHA-256$ であるかのみをチェックし、フィールドはチェックしておらず、MD5 形式では先頭が md5 であるかと長さのみをチェックし、16進数の文字であるかはチェックしていませんでした。パスワードは受け入れられますが、あとで使用できなくなります。
</p>
<li>データベースのエンコーディングとは異なるエンコーディングが指定されたlc_time設定の処理が修正されました。  (Juan Jos&eacute; Santamar&iacute;a Flecha, Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
ASCII 以外の文字を含むローカライズされた月または日の名前は、以前は予期せぬエラーまたはそのロケールで誤った出力を発生させていました。
</p>
<li>サーバのデータディレクトリ内のほかのファイルと同じ権限でcurrent_logfilesファイルが作成されるようになりました。  (Haribabu Kommi) (11)</li>
<p>
以前は log_file_mode で指定された権限を使用していましたが、バックアップユーティリティに問題を発生させる可能性がありました。
</p>
<li>単項マイナス演算子を含む場合について、operator_precedence_warning設定に基づくチェックの誤動作が修正されました。  (Rikard Falkeborn) (11)(10)(9.6)(9.5)</li>
<p>
以前は以下のような警告が発生していました。
</p>
<pre>
db=# SET operator_precedence_warning TO on;
db=# SELECT -random() IS NULL;
WARNING:  operator precedence change: IS is now lower precedence than -
row 1: SELECT -random() IS NULL;
                       ^
 ?column?
----------
 f
(1 row)
</pre>
<li>浮動小数点のサーバパラメータ値として「NaN」が拒否されるようになりました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<pre>
=# SET random_page_cost TO 'NaN';
ERROR:  parameter "random_page_cost" requires a numeric value
</pre>
<li>pg_class の各インデックスを再作成するときにアサート失敗を回避するために、REINDEX処理を並び替えて行うようになりました。  (Andres Freund, Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<li>パラメータ化されたダミーパスに対するプランナのアサート失敗が修正されました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
アサートを無効にしたビルドでは本障害によるユーザに見える影響はありません。
</p>
<li>SnapBuildInitialSnapshot() の結果に正しいテスト関数が挿入されるようになりました。  (Antonin Houska) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
コアコードでは考慮する必要はありませんが、いくつかの拡張ではその必要があります。SnapBuildInitialSnapshot() は主としてロジカルレプリケーションのために使われる内部実装関数です。
</p>
<li> Windows で断続的に「could not reattach to shared memory (共有メモリに再接続できなかった)」としてセッションの起動に失敗する不具合が修正されました。  (Noah Misch) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これまで認識されていなかった不具合の原因は、プロセスのデフォルトスレッドプール用のスレッドスタックの作成です。そのようなスタックが異なるメモリ領域に割り当てられるようになりました。
</p>
<li>Windows上のディレクトリスキャンにおけるエラー検出が修正されました。  (Konstantin Knizhnik) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
ディレクトリの読み取り権限がない、といったエラーが検出されないか正しく報告されず、そのかわりにディレクトリが空であるかのように静かに振る舞っていました。
</p>
<li>ecpg の文法問題を修正しました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
ecpg プログラムでセミコロンが欠けているとき（「SET variable TO DEFAULT」でなく）「SET variable = DEFAULT」の誤変換をひき起こし、サーバに拒否されるであろう誤った構文を出力しました。さらに、複数の型名を列挙した DROP TYPE または DROP DOMAIN コマンドは、実際には最初の型名だけが処理されていました。
</p>
<li>CREATE TABLE AS に対する ecpg の構文がサーバのものに同期されました。  (Daisuke Higuchi) (11)(10)(9.6)(9.5)</li>
<li>ecpg のインクルードファイル名の処理によるバッファオーバーランの可能性があり、修正されました。  (Liu Huailing, Fei Wu) (11)(10)(9.6)(9.5)(9.4)</li>
<li>ターゲットデータディレクトリ内の一時ファイルが削除できなかったためにpg_rewind が失敗していた不具合が修正されました。  (Michael Paquier) (11)</li>
<li>指定されたデータディレクトリが正しい PostgreSQLバージョンであることをpg_verify_checksums が確認するようになりました。  (Michael Paquier) (11)</li>
<li>リモート側でグループ化または集約を使用しているクエリに無相関の副SELECT、外部参照、またはパラメータシンボルである SELECT の選択リスト項目があってもcontrib/postgres_fdw がクラッシュしなくなりました。  (Tom Lane) (11)(10)</li>
<li>振り分けられた行を挿入するために選択されたリモートパーティションが、同一コマンドで後で更新される UPDATEサブプランの対象である場合にエラーを報告するように contrib/postgres_fdw が変更されました。  (Amit Langote, Etsuro Fujita) (11)</li>
<p>
以前は、このような状況が原因でサーバーがクラッシュしたり、UPDATE結果が不正確になったりしていました。
</p>
<li>contrib/pg_prewarm でプレウォームが何らかの理由で失敗してもバックグラウンドワーカプロセスが無制限に respawnしなくなりました。  (Mithun Cy) (11)</li>
<li>lo_unlink()呼び出しが失敗した場合に contrib/vacuumlo がクラッシュしなくなりました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<li>タイムゾーンライブラリのコピーが IANA tzcode release 2019a と同期されました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これによって Africa/Casablancaゾーンで 2440年の標準時とサマータイムの誤った遷移が出力されるという zic の小さな不具合が修正されます。また、zic に新しい -r オプションが追加されます。
</p>
<li>タイムゾーンデータファイルが tzdata release 2019a に更新されました。パレスチナとメトラカトラの夏時間法の変更とイスラエルの歴史的な修正が含まれます。   (11)(10)(9.6)(9.5)(9.4)</li>
<p>
Etc/UCT は Etc/UTC への後方互換性のあるリンクになりました。現在は一般的にタイプミスとされる略語の UCT を生成する別のゾーンではありません。PostgreSQL は依然としてゾーンの省略形として UCT の入力を受け入れますが、それを出力しません。
</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.5.16 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-5-16/</link>
		
		<dc:creator><![CDATA[高塚 遥 (Haruka Takatsuka)]]></dc:creator>
		<pubDate>Tue, 26 Feb 2019 02:01:17 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.5]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=1632</guid>

					<description><![CDATA[このリリースは 9.5.15 からの修正リリース（2019年2月14日リリース）です。 9.5.x からのアップデートではダンプ、リストアは不要です。 ただし、9.5.13 より前のバージョンから移行する場合には、9.5 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.5.15 からの修正リリース（2019年2月14日リリース）です。</p>
<p>9.5.x からのアップデートではダンプ、リストアは不要です。<br />
ただし、9.5.13 より前のバージョンから移行する場合には、<a href="/tech-blog/pgsql/9-5-13/">9.5.13 のリリース情報</a>を確認してください。</p>
<p><span id="more-1632"></span></p>
<h3>PostgreSQL 9.5.15 から 9.5.16 への変更点</h3>
<p>11.2、10.7、9.6.12、9.5.16、9.4.21 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<hr />
<ol>
<li>データ破損を回避するため、デフォルトでは fsync() に失敗したときにリトライするのではなく PANIC を出すようになりました。  (Craig Ringer, Thomas Munro) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
fsync()は OS にバッファをストレージに確実に書き出しさせる命令です。PostgreSQL は PANIC になるとサービス全体が停止します。
</p>
<p>
いくつかの人気の OS はカーネルデータバッファを書き出しできないときに、そのバッファを廃棄し、fsync() に失敗したものとして報告します。ここで PostgreSQL が fsync()要求を再発行して成功したとしても、実際にはデータは既に失われているので、データベース破損の危険性が残ります。代わりに PANIC状態にすることで、次に WALからのリカバリができます。WAL にはおそらく、ここにしか残っていないデータのコピーが含まれているでしょう。この振る舞いは確かに見苦しく非効率的ですが、あまり代替策がなく、また、幸いにもこのようなことは大変稀にしか起きません。
</p>
<p>
本動作の制御のため、新たな設定パラメータ data_sync_retry が追加されました。PostgreSQL を動作させるプラットフォームのカーネルがこのようなときにダーティデータバッファを廃棄しないと確信できるなら、これを on に設定して、従来通りの振る舞いにすることができます。
</p>
<li>ドキュメントに全メジャーバージョン系列ではなく当該メジャーバージョン系列のリリースノートのみを含めるようになりました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
※本ページでは引き続き、各バージョン系列を統合した形でリリース情報を掲載します。
</p>
<li>パーティションテーブル上で INCLUDE列を含むユニークインデックスの処理が修正されました。  (&Aacute;lvaro Herrera) (11)</li>
<p>
このような場合にユニーク条件が適切に検査されませんでした。
</p>
<li>パーティションテーブルの NOT NULL制約が各パーティション内で確実に効くようになりました。  (&Aacute;lvaro Herrera, Amit Langote) (11)(10)</li>
<p>
以下のように実行したときにパーティション（子テーブル）に NOT NULL 制約が付与されない動作がありました。
</p>
<pre>
db=# CREATE TABLE t4 (a int DEFAULT 1, b int NOT NULL DEFAULT 0)
       PARTITION BY LIST (a);
db=# CREATE TABLE t4c1 PARTITION OF t4 (a NOT NULL, b DEFAULT 1)
       FOR VALUES IN (1);
db=# INSERT INTO t4 (b) VALUES (NULL);
（修正前はここで violates not-null constraint のエラーが出ない）
</pre>
<li>パーティションをデタッチするとき、パーティションテーブルの制約に対して、カタログ状態を適切に更新するようになりました。  (Amit Langote, &Aacute;lvaro Herrera) (11)</li>
<p>
これまでは、パーティションテーブルの制約に対するpg_constraint.conislocalフィールドが、不適切に 'f'（false）のままになって、制約が除去（DROP）不能になることがありました。
</p>
<p>
本マイナーバージョンでは既におかしくなっているフィールドの値自体は補正されません。ダンプ/リストアや pg_upgrade でこの問題を解消できます。また、必要であれば、このカタログのフィールドを手動で補正することができます。デタッチ済みのパーティションに対する制約の本フィールドの値は 't'（true）です。
</p>
<pre>
（フィールド値を確認する SQL の例）
db=# SELECT conname, conislocal FROM pg_constraint;
           conname            | conislocal
------------------------------+------------
 cardinal_number_domain_check | t
 yes_or_no_check              | t
 t1_pkey                      | t
     （後略）
</pre>
<li>外部キー制約を持つパーティションテーブルで、パーティションをアタッチ・デタッチするときに、外部キー制約のためのトリガを正しく作成・削除するようになりました。  (Amit Langote, &Aacute;lvaro Herrera) (11)</li>
<p>
パーティションをデタッチした後に外部キー制約が正しく動作しないケースや、外部キー制約の除去（DROP）が出来なくなるケースが報告されました。
</p>
<li>パーティションテーブルで不要な重複した外部キー制約の生成が回避されました。  (&Aacute;lvaro Herrera) (11)</li>
<p>
これまで、各パーティションに対する外部キー制約とパーティションテーブル全体に対する外部キー制約が同じであった場合、そのようなパーティションには重複して制約が付加されていました。
</p>
<p>
これからは、このような場合でも一つの外部キー制約だけ作られるようになります。
</p>
<li>パーティションテーブルに対して ONLY を使ってインデックスが作られ、かつ、未だ属するパーティションが無い場合に、直ちにインデックスが有効であると印付けされるようになりました。  (&Aacute;lvaro Herrera) (11)</li>
<p>
このような場合に INVALID になっていましたが、その後で INVALID を解除する（有効にする）手段がありませんでした。
</p>
<pre>
（これまで以下のように実行したとき、t8_id_idx が INVALID になっていました）
db=# CREATE TABLE t8 (id int, v text) PARTITION BY RANGE (id);
db=# CREATE UNIQUE INDEX t8_id_idx ON ONLY t8 (id);

（上記の t8_id_idx は後に以下のようにすれば、無意味な使用法ではありません）
db=# CREATE TABLE t8_1 PARTITION OF t8 FOR VALUES FROM (0) TO (1000) ;
db=# CREATE UNIQUE INDEX t8_1_id_idx ON ONLY t8_1 (id);
db=# ALTER INDEX t8_id_idx ATTACH PARTITION t8_1_id_idx;
</pre>
<li>パーティションのデタッチ時に安全なテーブルロックレベルを使うようになりました。  (&Aacute;lvaro Herrera) (11)(10)</li>
<p>
これまでのロックレベルは弱すぎで、同時のテーブルに対する DDL実行が可能で、悪い結果をもたらすかもしれませんでした。
</p>
<p>
具体的には、パーティションに対するロックで、ACCESS SHARE であったロックレベルが SHARE UPDATE EXCLUSIVE に変更されました。また、特に 11.x 以降バージョンにおいて、インデックスに対するロックの保持期間がトランザクション終了までに延ばされました。
</p>
<li>一時テーブルであるパーティションテーブルおよび継承を持つ親テーブルに ON COMMIT DROP と ON COMMIT DELETE ROWS を適用する際の問題が修正されました。  (Michael Paquier) (11)(10)</li>
<p>
トランザクションのコミット時に以下のエラーが発生するケースが報告されました。
</p>
<pre>
ERROR: XX000: could not open relation with OID 16420
</pre>
<li>パーティションテーブルに対する COPY FREEZE が禁止されました。  (David Rowley) (11)(10)</li>
<p>
このような COPY は意図せぬエラーが発生し、エラーが生じない場合も正しく動作していませんでした。これからは以下のエラーが出るようになります。
</p>
<pre>
ERROR:  cannot perform FREEZE on a partitioned table
</pre>
<li>インデックス列が高速デフォルトである時のインデックス破損が修正されました。  (Andres Freund) (11)</li>
<p>
高速デフォルトとは、既にデータが格納されているテーブルに対してNULL 以外のデフォルト値を指定した ALTER TABLE ... ADD COLUMN により追加した列であることを指します。バージョン11 からこのような場合にも ALTER TABLE が高速に実行されるようになりました。
</p>
<li>高速デフォルト値を持つテーブルに対するALTER TABLE ... ALTER COLUMN ... TYPE ... でクラッシュすることがあり、修正されました。  (Andrew Dunstan) (11)</li>
<p>
「高速デフォルト」については前項を参照してください。
</p>
<li>複数のバッファロックを取得するときにデッドロックの可能性があり、回避されました。  (Nishant Fnu) (11)(10)(9.6)(9.5)(9.4)</li>
<li>GIN の VACUUM処理と同時のインデックス挿入との間でのデッドロックが回避されました。  (Alexander Korotkov, Andrey Borodin, Peter Geoghegan) (11)(10)</li>
<p>
この修正はバージョン10 で導入された性能改善を部分的に元に戻します。それは GIN のポスティングツリーのページを削除するときに、ロックされるインデックスページ数を減らそうとするものでした。
</p>
<p>
なお、ここでのデッドロックは、デッドロック自動検出で ERROR を生じさせるものではなく、ハングアップを生じさせるものです。
</p>
<li>ホットスタンバイ問い合わせと GINインデックスのページ削除のリプレイとの間のデッドロックが回避されました。  (Alexander Korotkov) (11)(10)(9.6)(9.5)(9.4)</li>
<li>ロジカルレプリケーションで対象テーブルに式インデックスや部分インデックスが使われている場合に、クラッシュする可能性があり、修正されました。  (Peter Eisentraut) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
修正前バージョン同士のレプリケーションでクラッシュが起きるのは、通常はパブリッシャ側です。
</p>
<li>VACUUM FULL や CLUSTER などによるテーブル書き換え中において、高負荷で無用な TOASTデータのロジカルデコーディングを回避するようになりました。  (Tomas Vondra) (11)(10)(9.6)(9.5)(9.4)</li>
<li>同期レプリケーションが有効なときに、一部の WAL sender プロセスを止めるロジックが修正されました。  (Paul Guo, Michael Paquier) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
潜在的に同期レプリケーションによる保証を毀損するおそれがありました。また、9.4.xバージョンではアサート失敗を起こす可能性もありました。
</p>
<li>タプルを削除する WALレコードで誤ったレプリカアイデンティ属性を書き込む可能性があり、回避されました。  (Stas Kelvich) (11)(10)(9.6)(9.5)(9.4)</li>
<li>ビューや外部テーブルへの COPY のときに、WAL出力省略による最適化を誤って用いないように修正されました。  (Amit Langote, Michael Paquier) (11)(10)</li>
<p>
ここでのWAL出力省略による最適化とは以下のようなケースです。このときトランザクション内で作成するのがビューや外部テーブルであるなら、本来 WAL出力の省略はできません。
</p>
<pre>
BEGIN;
CREATE TABLE t21 (id int, v text);
COPY t21 FROM STDIN CSV;
1,aaaaa
2,bbbbb
.
COMMIT;
</pre>
<li>アーカイバが次にアーカイブするファイルを選ぶときにWALデータファイルよりも WALヒストリファイルを優先するようになりました。  (David Steele) (11)(10)(9.6)(9.5)</li>
<p>
これによりタイムライン変更の追随をより早期に行えるようになります。
</p>
<li>SET句に副問い合わせを使った UPDATE文でクラッシュする可能性があり、修正されました。  (Tom Lane) (11)(10)(9.6)(9.5)</li>
<p>
なお、明らかにクラッシュが生じるのはバージョン 9.6.x と 10.x のみです。以下のような SQL でクラッシュする例が報告されました。
</p>
<pre>
db=# CREATE TABLE t23_1 (a VARCHAR(1));
db=# CREATE TABLE t23_2 (b VARCHAR(1));
db=# INSERT INTO t23_1 VALUES ('A');
db=# INSERT INTO t23_2 VALUES ('A');
db=# UPDATE t23_1 SET (a) = (SELECT b FROM t23_2 WHERE t23_2.b = t23_1.a)
       WHERE 'X' NOT IN ('Y', 'Z');
</pre>
<li>json_populate_recordset()、json_to_recordset()関数、および、これらの jsonb型版の関数に0行を与えたときのクラッシュが修正されました。  (Tom Lane) (11)</li>
<pre>
（クラッシュをひき起こす実行例）
db=# CREATE TYPE typ24 AS (id int);
db=# SELECT * FROM json_populate_recordset(NULL::typ24,'[]');
</pre>
<li>libxml2 ライブラリが null のエラーメッセージを返してきたときにバックエンドプロセスがクラッシュするのが回避されました。  (Sergio Conde G&oacute;mez) (11)(10)(9.6)(9.5)(9.4)</li>
<li>多数の列（およそ 800 以上）を持つテーブルに対する誤った JIT のタプルデフォーミングが修正されました。  (Andres Freund) (11)</li>
<p>
SQL実行時のバックエンドプロセスのクラッシュが報告されました。
</p>
<li>ハッシュによるグルーピングで性能と余分なメモリ使用の問題がいくつか修正されました。  (Andres Freund) (11)</li>
<li>照合順序の割り当ての誤動作により、不要なグルーピング関係のパーサエラーが生じていたものが修正されました。  (Andrew Gierth) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
一部のケースでは、照合順序が適用されるデータ型での処理があるときに、マッチすべき式がマッチしませんでした。すなわち、誤った問い合わせ結果が返る可能性があります。
</p>
<p>
CASE式とグループ化（GROUP BY）を使った問い合わせで障害が報告されました。
</p>
<li>CALL文の引数で照合順序の影響をうける式のパースが修正されました。  (Peter Eisentraut) (11)</li>
<p>
例えば以下のような CALL文は 'a' と 'b' が当該ロケールでどちらが先になるかということの影響を受けます。修正前はこのような場合にロケールに基づく照合順序が反映されませんでした。
</p>
<pre>
db=# CALL proc29(least('a', 'b'), 'c');
</pre>
<li>CALL文の引数リストでエラーを発見した後に適切なクリーンアップ処理が確実に行われるようになりました。  (Tom Lane) (11)</li>
<p>
引数に関するエラーが出る CALL文を繰り返し実行したときに、2回目以降に不適切なエラーメッセージが出る動作が報告されました。
</p>
<li>LEAST() または GREATEST() の元となっている Btree の比較関数が LEAKPROOF であるかを検査するようになりました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これまで検査していませんでした。実際の Btree 比較関数からの情報漏れを起こすのは一般に困難ですが、原理的には起こりえます。
</p>
<li>Gatherプランノードの上と下の両方に入れ子ループを伴う問い合わせについて、誤ったプラン作成が修正されました。  (Tom Lane) (11)(10)(9.6)</li>
<p>
誤った問い合わせ結果が返る動作が報告されました。
</p>
<p>
両階層の入れ子ループが同じ変数を各々のプランナツリー構造上の右手側に渡す必要がある場合、誤ったプランが生成されると考えられます。
</p>
<li>外部テーブルのスキャン時にラテラル参照が評価されなければならないという問い合わせの、誤ったプラン作成が修正されました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
LATERAL句による副問い合わせを伴う外部テーブルに対する SELECT文で以下のようなエラーが出るケースが報告されました。
</p>
<pre>
ERROR:  attribute number 2 exceeds number of columns 1
</pre>
<li>行比較の最初の列がインデックス列と一致して、しかし続く列は一致せず、また、インデックスが INCLUDE列を持っているときに、プランナがエラーになるのを修正しました。  (Tom Lane) (11)</li>
<p>
以下のようなエラーが発生します。
</p>
<pre>
db=# CREATE TABLE t34 (c1 int, c2 int, c3 int, c4 int,
       CONSTRAINT covering PRIMARY KEY (c1, c2) INCLUDE (c3, c4));
db=# SELECT * FROM t34 WHERE (c1, c2, c3) &lt; (1, 2, 3);
ERROR:  operator 97 is not a member of opfamily 8
</pre>
<li>稀な場合のマージ結合コストの過小見積を修正しました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
外側のキー範囲が内側のキー範囲よりもとても小さいときに、たとえ内側に重複キーが大量にあって不適切な選択であるとしても、プランナがマージ結合を好んでいた可能性があります。
</p>
<li>問い合わせが何千ものインデックス利用可能な項を含むときの O(N^2) でのプラン作成時間の増大が回避されました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<li>属するテーブルが多い大規模な継承あるいはパーティショニングテーブルに対して、プラン作成速度が改善されました。  (Amit Langote, Etsuro Fujita) (11)</li>
<p>
1000パーティションのパーティションテーブルで 11.1バージョンのプラン作成時間が10.x や 11.0 と比べて 1000倍以上になる動作が報告されました。
</p>
<li>ANALYZE の同時更新された行の処理が改善されました。  (Jeff Janes, Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これまで、実行中のトランザクションで削除された行を ANALYZE の統計情報採取では無視していましたが、これを含めるのと比べてより大きな不整合をもたらすことがわかりました。これからは事実上、ANALYZE開始時の MVCCスナップショットに一致するようになりました。
</p>
<li>TRUNCATE が他セッションの一時テーブルである継承子テーブルを無視するようになりました。  (Amit Langote, Michael Paquier) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これは TRUNCATE を他のコマンドの振る舞いに合わせます。これまでは、このような場合にたいていエラーになっていました。
</p>
<p>
以下の動作が発生します。
</p>
<pre>
db=# CREATE TABLE t39 (id int);

    （別セッションで）
    db=# CREATE TEMP TABLE t39c (LIKE t39) INHERITS (t39);

db=# TRUNCATE t39;
ERROR:  cannot truncate temporary tables of other sessions
</pre>
<li>正しいテーブルに対する実行時統計情報のカウンタを更新するように TRUNCATE が修正されました。  (Tom Lane) (11)(10)(9.6)(9.5)</li>
<p>
TRUNCATEするテーブルが TOASTテーブルを持っている場合、TOASTテーブルのカウンタが代わりにリセットされていました。
</p>
<li>ALTER TABLE .. ONLY ADD COLUMN .. IF NOT EXISTS が正しく動作するように修正されました。  (Greg Stark) (11)(10)(9.6)</li>
<p>
「ONLY」を付けると「IF NOT EXISTS」指定が効きませんでした。
</p>
<pre>
db=# CREATE TABLE t41 (c1 int);
db=# ALTER TABLE ONLY t41 ADD COLUMN IF NOT EXISTS c1 int;
ERROR:  column "c1" of relation "t41" already exists
（IF NOT EXISTS 指定が効かない）

db=# ALTER TABLE t41 ADD COLUMN IF NOT EXISTS c1 int;
NOTICE:  column "c1" of relation "t41" already exists, skipping
ALTER TABLE
（ONLY が無ければ機能する）
</pre>
<li>ホットスタンバイで UNLISTEN が可能になりました。  (Shay Rojansky) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
ホットスタンバイで LISTEN はできないので、これは必然的に何もしません。しかしながらダミー操作を可能にすることで、クライアントでのセッション状態のリセットを簡単にします。
</p>
<li>一部のスキーマとデータ型のアクセス制御リストでのロールの依存性の欠落が修正されました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
一部の場合に許可を与えられたロールを落としてしまうことがあり得ました。これが直ちに問題をひき起こすことはありませんが、後のダンプ/リストアや pg_upgrade実行で失敗します。症状としては、全てが数字のロール名に権限を付与しようとします。
</p>
<p>
以下は pg_upgrade の中で pg_restore を実行したときのエラー発生例です。
</p>
<pre>
pg_restore: [archiver (db)] could not execute query: ERROR: role "33757" does not exist
Command was: GRANT ALL ON SCHEMA "regress_rls_schema" TO "33757";
</pre>
<li>二相トランザクション内でセッションの一時スキーマの使用が防止されました。  (Michael Paquier) (11)(10)</li>
<p>
二相トランザクション内で一時テーブルにアクセスすることは、長らく禁止されていましたが、一時オブジェクトに対する他の操作で問題が起きる可能性がまだありました。
</p>
<li>外部キー制約を追加または削除した後、確実にリレーションキャッシュが適切に更新されるようになりました。  (&Aacute;lvaro Herrera) (11)(10)(9.6)</li>
<p>
この見落としにより、既存セッションにおいて新たに作られた制約が効かなかったり、削除された制約が継続して効いていたりする可能性がありました。
</p>
<li>制約の名前変更の後、適切にリレーションキャッシュが適切に更新されるようになりました。  (Amit Langote) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
ALTER TABLE ... RENAME CONSTRAINT ... TO ... を実行した後に、続いてそのテーブルに関連する DDL を実行したときに、変更する前の名前の制約が存在しないという以下のようなエラーが出る動作が報告されました。
</p>
<pre>
ERROR:  constraint "const_aaa" for table "t46" does not exist
</pre>
<li>同時実行のホットスタンバイ問い合わせに不整合状態を参照されないように、GiSTインデックスのマイクロVACUUM操作のリプレイが修正されました。  (Alexander Korotkov) (11)(10)(9.6)</li>
<li>空の GINインデックスページの早過ぎる回収を防止しました。これは同時実行の検索で失敗をひき起こしていました。  (Andrey Borodin, Alexander Korotkov) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
本障害によりハングアップが生じるケースが報告されました。
</p>
<li>浮動小数点から整数への型変換での限界値の障害が修正されました。  (Andrew Gierth, Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
最大の有効な整数値を僅かに上回る値は拒絶されないおそれがありました。それで、オーバーフローして、替わりに最小の有効な整数が生じました。また、最小あるいは最大の整数値に丸めるべき値が誤って拒絶されるかもしれませんでした。
</p>
<pre>
（障害動作例）
db=# SELECT '32767.4'::float8::int2;
ERROR:  smallint out of range
　→ 32767 となるべき

db=# SELECT '9223372036854775807'::float8::int8;
         int8
----------------------
 -9223372036854775808
(1 row)
　→ 「ERROR:  bigint out of range」を出すべき
</pre>
<li>pg_hba.conf の LDAP認証の ldapserverパラメータにおける、ホスト名のスペース区切りリストのパースが修正されました。  (Thomas Munro) (11)</li>
<p>
以下のエラーになって、複数ホストの指定が動作しないことが報告されました。
</p>
<pre>
LOG:  could not initialize LDAP: Bad parameter to an ldap routine
</pre>
<li>PAM認証要求を構成するときに、接続が Unixソケット経由の場合には、PAM_RHOST変数を設定しないようになりました。  (Thomas Munro) (11)(10)(9.6)</li>
<p>
これまでは、この変数に「[local]」を設定していましたが、これはホスト名であるはずなので全く役に立ちませんでした。「[local]」の文字列で DNS検索が発生して認証によけいな遅延が生じました。
</p>
<li>client_min_messages に ERROR より高レベルを設定することが禁止されました。  (Jonah Harris, Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これまでは FATAL や PANIC を設定して、通常のエラーメッセージをクライアントに送らないようにすることができました。しかしながら、これは PostgreSQLプロトコル仕様で提示される保証事項に反し、一部のクライアントを大変に混乱させます。
</p>
<p>
リリース済みのバージョン系列においては、FATAL、PANIC の設定は ERROR と解釈されます。バージョン 12.x 以降においては、これら設定は拒絶されます。
</p>
<li>ecpglib が setlocale() よりも優先して uselocale() や _configthreadlocale()を使うように修正しました。  (Michael Meskes, Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
setlocale() がスレッドローカルでなく、おそらくスレッドセーフでもないため、以前のコードはマルチスレッド化された ecpgアプリケーションで問題を起こしました。
</p>
<li>ecpg の SQLDA（SQL Descriptor Area）を通して渡された数値データに対する誤った結果を修正しました。  (Daisuke Higuchi) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
ゼロから始まる値が正しくコピーされませんでした。
</p>
<li>psql の、書き出し先を指定した g メタコマンドが COPY TO STDOUT で動作するように修正されました。  (Daniel V&eacute;rit&eacute;) (11)(10)(9.6)(9.5)</li>
<p>
これまでは g は COPYコマンドを実行できましたが、g の書き出し先オプションは何であれ無視されていて、データはいつでも通常の問い合わせの出力先に出されていました。
</p>
<li>psql の LaTeX出力形式が特殊文字を適切に処理できるようになりました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
バックスラッシュやその他の ASCII記号文字が正しく処理されず、ドキュメントの構文エラーや誤った文字の出力をもたらしていました。
</p>
<li>pgbench の乱数生成が --random-seed=N が指定された場合には完全に決定的でプラットフォーム独立になりました。  (Fabien Coelho, Tom Lane) (11)</li>
<p>
プラットフォームによっては標準ライブラリの srandom()/random() が非決定的な乱数を返すことがあるため、PostgreSQL自身で実装した乱数生成関数を用いるようになりました。
</p>
<li>一時ファイルを適切に無視するように pg_basebackup と pg_verify_checksums が修正されました。  (Michael Banck, Michael Paquier) (11)</li>
<li>pg_dump の間接的に主キーに依存するマテリアライズドビューの処理が修正されました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
本障害はこのようなビューに対して紛らわしいダンプアーカイブエントリをもたらし、アーカイブ項目が正しいセクション順序に無いという無害な警告をひき起こしました。「--section」など、このラベルに依存している選択的なリストアのオプションでは、無害でもなくて、誤動作するかもしれません。
</p>
<p>
以下の WARNING が発生します。
</p>
<pre>
pg_dump: [archiver] WARNING: archive items not in correct section order
</pre>
<li>pg_dump が ALTER INDEX .. SET STATISTICS .. コマンドを含むようになりました。  (Michael Paquier) (11)</li>
<p>
インデックス式に統計情報ターゲット数を付与できるようになったときに、pg_dump についても対応すべきところ、取りこぼされていて、ダンプ/リストアで設定が失われていました。
</p>
<li>pg_dump の OID を持ったテーブルのダンプが修正されました。  (Peter Eisentraut) (11)</li>
<p>
最初のテーブルに対して、必要な場合でも WITH OIDS句が取りこぼされていました。
</p>
<li>pg_dump や pg_restore がエラー報告しようとするときの、一部プラットフォームでの NULLポインタ参照によるクラッシュが回避されました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<li>contrib/amcheck からのインライン圧縮データによる偽性のインデックス破損報告が防止されました。  (Peter Geoghegan) (11)</li>
<li>COPY FROM PROGRAM がプログラム出力の読み込みを早期に止めるときに、SIGPIPEエラーを適切に無視するようになりました。  (Tom Lane) (11)(10)</li>
<p>
このケースは実際のところ直接の COPY では到達可能でありませんが、contrib/file_fdw を使うときには発生する可能性があります。
</p>
<li>バージョン8.4 以前で作られた空の hstore値に対するハッシュ値を正しく計算するように contrib/hstore が修正されました。  (Andrew Gierth) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
これまでの実装では新たなバージョンで作られた空の hstore値に対して同じ結果を返しませんでした。そのため、ハッシュ結合やハッシュ集約で誤った結果がもたらされる可能性がありました。テーブルに8.4以前に当初格納されたデータが含まれていて、これまでダンプ/リストアをしていない場合、hstore型の列に対するハッシュインデックスを全て再作成することが推奨されます。
</p>
<li>contrib/intarray の gist__int_opsインデックスクラスに大きな入力を与えた場合の、クラッシュと過大な実行時間が回避されました。  (Andrew Gierth) (11)(10)(9.6)(9.5)(9.4)</li>
<p>
intarray拡張を使って整数配列にインデックスを作って、データを投入するとき、クラッシュする動作が報告されました。また、巨大なメモリ確保を試みて「ERROR:  invalid memory alloc request size ...」になるケースもあります。
</p>
<li>configure で python が見つからないとき、python3 と python2 を探すようになりました。  (Peter Eisentraut) (11)(10)</li>
<p>
バージョン番号付きの python実行ファイルが無いプラットフォームで、明示的に PYTHON 変数を指定することなく PL/Python が設定できるようになります。
</p>
<li>インストールされるヘッダファイルに JITに関するヘッダが含まれるようになりました。  (Donald Dong) (11)</li>
<li>pgxs によるビルドにて新たな Makefile変数 PG_CFLAGS、PG_CXXFLAGS、PG_LDFLAGS がサポートされました。  (Christoph Berg) (11)(10)(9.6)(9.5)(9.4)</li>
<li>Perlコードのビルドスクリプトで、最近の perl は '.' を検索パスに含まないことを想定するようになりました。  (Andrew Dunstan) (11)(10)(9.6)(9.5)(9.4)</li>
<li>OpenBSD のサーバコマンドラインオプション解析問題が修正されました。  (Tom Lane) (11)(10)(9.6)(9.5)(9.4)</li>
<li>set_rel_pathlist_hook を呼び出す箇所が変更され、拡張機能がそのフックを使ってパラレルクエリの部分パスを提供できるようになりました。  (KaiGai Kohei) (11)(10)(9.6)</li>
<p>
既存のユースケースには影響を与えないと考えられます。
</p>
<li>タイムゾーンデータファイルが tzdata release 2018i に更新されました。   (11)(10)(9.6)(9.5)(9.4)</li>
<p>
カザフスタン、メトラカットラ、サントメ・プリンシペの夏時間法の変更、香港と多数の太平洋諸島での歴史的修正が含まれます。
</p>
<p>
また、カザフスタンの Qyzylordaゾーンは 2つに分かれ、新ゾーン Asia/Qostanay が作られました。一部の地域は UTCオフセットを変更しません。
</p>
<li>autovacuum が、残った一時テーブルをより積極的に削除するように、また、DISCARD TEMP の際にも残った一時テーブルを削除するようになりました。  (&Aacute;lvaro Herrera) (10)(9.6)(9.5)(9.4)</li>
<p>
これにより、クラッシュしたセッションの残骸がより速やかに片付けられます。
</p>
<li>赤黒木(red black tree)のサポート関数が rb プレフィックスを使わず、rbt プレフィックスを使うように改名されました。  (Tom Lane) (10)</li>
<p>
これにより PL/Ruby を壊す Ruby 関数との名前衝突を避けます。影響を受ける他の拡張は無いと思われます。PostgreSQL 11.1 で修正されていましたが、10.x 系列にも適用されました。
</p>
<li>configureで選択されるスレッド関連のコンパイラフラグとライブラリが、以降のPostgreSQLリリースに一致するように調整されました。  (Tom Lane) (9.5)(9.4)</li>
<p>
9.4および9.5バージョン系列で以前に使われたコードは、一部の新しいプラットフォームでは完全に失敗するため、9.6以降で使われるものに一致されました。
</p>
</ol>

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

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