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

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

<image>
	<url>https://www.sraoss.co.jp/tech-blog/wp-content/uploads/2018/07/blog-icon-150x150.png</url>
	<title>PostgreSQL 11.6 &#8211; SRA OSS Tech Blog</title>
	<link>https://www.sraoss.co.jp/tech-blog/</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>PostgreSQL 11.7 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-7/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Fri, 28 Feb 2020 05:15:43 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.6]]></category>
		<category><![CDATA[PostgreSQL 11.7]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=5719</guid>

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

					<description><![CDATA[このリリースは 11.5 からの修正リリース（2019年11月14日リリース）です。 11.x からのアップデートではダンプ、リストアは不要です。 ただし、contrib/intarray で &lt;@ 演算子に Gi ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 11.5 からの修正リリース（2019年11月14日リリース）です。</p>
<p>11.x からのアップデートではダンプ、リストアは不要です。<br />
ただし、contrib/intarray で &lt;@ 演算子に GiSTインデックスを使っている場合には、下記の 83番の項目を確認してください。<br />
11.1より前のバージョンからのアップデートの場合には <a href="/tech-blog/pgsql/11-1/">11.1 のリリース情報</a>も確認してください。</p>
<p><span id="more-4957"></span></p>
<h3>PostgreSQL 11.5 から 11.6 への変更点</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>
	</channel>
</rss>
