<?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.1 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql-11-1/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:23:18 +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.1 &#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.2 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/11-2/</link>
		
		<dc:creator><![CDATA[データベース技術グループ]]></dc:creator>
		<pubDate>Tue, 26 Feb 2019 02:04:22 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 11]]></category>
		<category><![CDATA[PostgreSQL 11.1]]></category>
		<category><![CDATA[PostgreSQL 11.2]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=1619</guid>

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