<?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.1 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql-9-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>Fri, 30 Oct 2026 08:10:22 +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.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 9.1.24 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-1-24/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Thu, 27 Oct 2016 01:06:31 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.1]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=1819</guid>

					<description><![CDATA[このリリースは 9.1.23 からの修正リリース（2016年10月27日リリース）です。 9.1.x からのアップデートではダンプ、リストアは不要です。 また、9.1.16 より前のバージョンからアップデートを行う場合は ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.1.23 からの修正リリース（2016年10月27日リリース）です。</p>
<p>9.1.x からのアップデートではダンプ、リストアは不要です。</p>
<p>また、9.1.16 より前のバージョンからアップデートを行う場合は <a href="/tech-blog/pgsql/9-1-16/">9.1.16 に関する技術情報</a> を参照してください。</p>
<p>本バージョンが 9.1.x の最終リリースとなります。</p>
<p><span id="more-1819"></span></p>
<h3>PostgreSQL 9.1.23 から 9.1.24 への変更点</h3>
<p>9.6.1、9.5.5、9.4.10、9.3.15、9.2.19、9.1.24 の各バージョンが同時にリリースされており、 本ページでは共通の記載としています。 各修正項目が適用されるバージョン系列番号を 項目末尾に括弧書きで記載しています。<br />
<hr />
<ol>
<li>フリースペースマップおよび可視性マップの切り詰めについてのWAL記録について修正されました。 (Pavan Deolasee, Heikki Linnakangas) (9.6)(9.5)(9.4)(9.3)</li>
<p>
クラッシュリカバリに際してこれらファイルが正しく復旧しなかったり、スタンバイサーバに誤った書き込みがされる可能性がありました。
</p>
<p>
フリースペースマップの不正な項目は、リレーションの既に切り詰めされたページへのアクセスをひき起こし、典型的には以下のようなエラーが出ます。
</p>
<pre>ERROR:  could not read block 28991 in file "base/16390/572026": read only 0 of 8192 bytes
</pre>
<p>
フリースペースマップを再生成させるには、サービスを正常停止（smartモードかfastモードで停止）して、データベースクラスタディレクトリ内の.fsmファイルを手動で削除して、サービスを再起動してください。フリースペースマップが既に壊れているかを個別に検査する手順は、以下ページを参照ください。
</p>
<p>
https://wiki.postgresql.org/wiki/Free_Space_Map_Problems
</p>
<p>
可視性マップの障害は、ページチェックサムを有効にしていると、チェックサム検査エラーをひき起こすこともあります。
</p>
<p>
可視性マップを再生成させるには、contrib/pg_visibility 拡張モジュールのpg_truncate_visibility_map() 関数を使用できます。サービス停止して、.vmファイルを手動で削除して、サービス再起動する方法でも良いです。
</p>
<li>pg_upgrade が可視性マップを9.6フォーマットに書き換えしたときデータ破損の可能性があり、修正されました。 (Tom Lane) (9.6)</li>
<p>
ビッグエンディアンのマシンで新たな可視性マップのバイト列が誤った順で書かれて、完全に誤ったマップをもたらしました。また、Windows では旧マップがテキストモードで読み取られて、マップのバイト列に改行コード CR(0x0D) LF(0x0A) の並びが含まれているとき、誤った結果をもたらしました。
</p>
<p>
pg_upgrade を使用していて上記のいずれかに該当しているなら可視性マップが壊れていると考えられます。
</p>
<p>
contrib/pg_visibility 拡張モジュールの pg_truncate_visibility_map() 関数を使って可視性マップを再生成することができます。サービス停止して、.vmファイルを手動で削除して、サービス再起動する方法でも良いです。
</p>
<p>
以下のページも参照ください。
</p>
<p>
https://wiki.postgresql.org/wiki/Visibility_Map_Problems
</p>
<li>INSERT ... ON CONFLICT による自己衝突の場合にトランザクション直列化失敗のエラーを投げないようになりました。 (Thomas Munro, Peter Geoghegan) (9.6)(9.5)</li>
<p>
ここでの自己衝突とは以下例のようなケースです。SERIALIZABLE またはREPEATABLE READ トランザクション隔離レベルで発生します。修正後、本ケースではエラー無しに 1件だけレコードが挿入されます。
</p>
<pre>db1=# CREATE TABLE t3 (id int primary key);

db1=# START TRANSACTION ISOLATION LEVEL SERIALIZABLE;

db1=# INSERT INTO t3(id) VALUES (1),(1) ON CONFLICT DO NOTHING;
ERROR:  could not serialize access due to concurrent update
</pre>
<li>DISTINCT を使う集約関数の実行において、解放後のメモリを使用する障害が修正されました。 (Peter Geoghegan) (9.6)</li>
<p>
以下のような SQL が該当します。
</p>
<pre>SELECT string_agg(DISTINCT col1, ',' ORDER BY col1) FROM t4;
</pre>
<p>
バックエンドプロセスのクラッシュや誤った問い合わせ結果を引き起こすおそれがあります。特に Windows むけビルドで発生が報告され、再現が確認されました。
</p>
<li>ウィンドウ関数として使われる多様集約の誤った扱いが修正されました。 (Tom Lane) (9.6)</li>
<p>
集約の遷移関数に、その第一引数と結果が状態のデータ型でなく集約の出力のデータ型だと示されていました。このことは多様の遷移関数でエラーやクラッシュをもたらしました。
</p>
<p>
CREATE AGGREGATE で集約関数を作るときに、状態遷移関数や最終計算関数の引数型や返し値型に anyelement や anyarray 等を使う多様関数を指定した場合で、集約の出力と状態でデータ型が異なる場合に該当します。エラーやクラッシュが生じるのは、作成した集約関数を実行したときです。
</p>
<pre>(エラー発生例:)
db1=# CREATE FUNCTION first_el(anyarray) RETURNS anyelement
        AS 'select $1[1]' LANGUAGE sql STRICT IMMUTABLE;

db1=# CREATE AGGREGATE first_el_agg_f8(float8)
        (SFUNC = array_append, STYPE = float8[], FINALFUNC = first_el);

db1=# SELECT first_el_agg_f8(x::float8) OVER (order by x)
        FROM generate_series(1,5) x;
ERROR:  input data type is not an array

(本来の期待される出力は以下:)
 first_el_agg_f8 
-----------------
               1
               1
               1
               1
               1
(5 rows)
</pre>
<li>行単位セキュリティが有効なテーブルの列名リストを伴う COPY が修正されました。 (Adam Brightwell) (9.6)(9.5)</li>
<pre>(エラー発生例:)
db1=# CREATE ROLE user6;
db1=# CREATE TABLE t6 (a int, b int, c int);
db1=# INSERT INTO t6 VALUES (1,4,1),(2,3,2),(3,2,3),(4,1,4);
db1=# CREATE POLICY p6 ON t6 FOR SELECT USING (a % 2 = 0);
db1=# ALTER TABLE rls_t6 ENABLE ROW LEVEL SECURITY;
db1=# ALTER TABLE rls_t6 FORCE ROW LEVEL SECURITY;
db1=# GRANT SELECT ON TABLE t6 TO user6;

db1=# SET SESSION AUTHORIZATION user6;
db1=&gt; COPY t6 TO stdout;
2       3       2
4       1       4
db1=&gt; COPY t6 (a, b) TO stdout;
ERROR:  missing FROM-clause entry for table "a"

(本来の期待される出力は以下:)
2       3
4       1
</pre>
<li>track_io_timing = on であるとき、EXPLAIN が有効な XML を出力するように修正されました。 (Markus Winand) (9.6)(9.5)(9.4)(9.3)(9.2)</li>
<p>
これまでは XML形式のとき、「&lt;I/O-Read-Time&gt;」など、文法的に不正なタグが出力されました。タグ名(XML要素名)に使われるアルファベット、数字、「-」「_」「.」以外の文字は「-」で置き換えられるようになりました。つまり、前述の文字列は「&lt;I-O-Read-Time&gt;」と出力されます。
</p>
<li>準備されたトランザクション(二相コミットのトランザクション)でTRUNCATE の統計情報更新が修正されました。 (Stas Kelvich) (9.6)(9.5)</li>
<p>
pg_stat_*_tables の n_live_tup、n_dead_tup に相当する統計値が、TRUNCATE で 0 にならない動作がありました。
</p>
<li>CREATE/ALTER TABLE にて継承された CHECK制約のマージにおける、いくつかの障害が修正されました。 (Tom Lane, Amit Langote) (9.6)(9.5)(9.4)(9.3)(9.2)</li>
<p>
どちらから先でも親テーブル、子テーブルに対して同一の CHECK制約を追加することが可能になりました。これまで ALTER TABLE で後から加えるとエラーになっていたものが適切にマージされます。以下に例を示します。
</p>
<pre>db1=# CREATE TABLE t9p(a int);
db1=# CREATE TABLE t9c() INHERITS ( t9p );
db1=# ALTER TABLE t9p ADD CONSTRAINT check_a CHECK (a &gt; 0);

(これまでのバージョンの動作)
db1=# ALTER TABLE t9c ADD CONSTRAINT check_a CHECK (a &gt; 0);
ERROR:  constraint "check_a" for relation "t9c" already exists

(修正後の動作)
db1=# ALTER TABLE t9c ADD CONSTRAINT check_a CHECK (a &gt; 0);
NOTICE:  merging constraint "check_a" with inherited definition
</pre>
<p>
親テーブルからの有効な制約と子テーブル上の NOT VALID な制約の併合を防止します。同様に NO INHERIT な子テーブルの制約と継承された制約の併合も防止します。これまでは誤ってマージされてしまっていました。以下に例を示します。
</p>
<pre>(これまでのバージョンの動作)
db1=# CREATE TABLE t9p (a int, CONSTRAINT CHECK_a CHECK (a &gt; 0));
db1=# CREATE TABLE t9c (CONSTRAINT CHECK_a CHECK (a &gt; 0) NO INHERIT) INHERITS (t9p);
NOTICE:  merging constraint "check_a" with inherited definition

(修正後の動作)
db1=# CREATE TABLE t9p (a int, CONSTRAINT CHECK_a CHECK (a &gt; 0));
db1=# CREATE TABLE t9c (CONSTRAINT CHECK_a CHECK (a &gt; 0) NO INHERIT) INHERITS (t
9p);
ERROR:  constraint "check_a" conflicts with inherited constraint on relation "t9c"
</pre>
<li>min_wal_size と max_wal_size に対する pg_settings.unit で実用的な値を表示するようになりました。 (Tom Lane) (9.6)(9.5)</li>
<p>
従来 NULL でしたが、以下のようになります。
</p>
<pre>db1=# SELECT name, unit FROM pg_settings WHERE name IN ('min_wal_size', 'max_wal_size');
     name     | unit
--------------+------
 max_wal_size | 16MB
 min_wal_size | 16MB
(2 rows)
</pre>
<li>jsonb_set() で配列要素の置換が修正されました。 (Tom Lane) (9.6)</li>
<p>
対象が存在するJSON配列要素である場合、新たな値で置き換えられるのでなく、削除されていました。
</p>
<pre>(障害動作例: 最も外側の JSON配列のゼロ番目を '100' で置き換える指定)
db1=# SELECT jsonb_set('[0,1,null,3]', '{0}', '100', false);
  jsonb_set
--------------
 [1, null, 3]
(1 row)

(正しい応答:)
        jsonb_set
-------------------------
 [100, 1, null, 3]
(1 row)
</pre>
<li>バッファのロックを保持せずにタプル可視性をテストすることに起因する滅多に起こらないデータ破損について、回避されました。 (Thomas Munro, Peter Geoghegan, Tom Lane) (9.6)(9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
特に外部キーチェックの処理で一貫性に欠けたデータが生じる可能性がありました。
</p>
<li>サーバ再起動時にコミットタイムスタンプを保護するようになりました。 (Julien Rouhaud, Craig Ringer) (9.6)(9.5)</li>
<p>
track_commit_timestamp = on のとき、クリーンなサーバ再起動の後に、古いコミットタイムスタンプがアクセス不能になってました。
</p>
<p>
以下のように再起動前に取得できたタイムスタンプが、取得できなくなる動作が生じます。
</p>
<pre>(エラー動作例: NULL は *NULL* と表示)
db1=# SELECT txid_current();
 txid_current
--------------
        12345
(1 row)
db1=# SELECT pg_xact_commit_timestamp('12340'); -- 最近のトランザクション
   pg_xact_commit_timestamp
-------------------------------
 2016-10-31 16:40:58.681952+09
(1 row)

db1=# q

$ pg_ctl restart
$ psql db1

db1=# SELECT pg_xact_commit_timestamp('12340');
 pg_xact_commit_timestamp
--------------------------
 *NULL*
(1 row)
</pre>
<li>ロジカルWALデコーディングが、サブトランザクションの WAL出力がディスクに溢れるほど大きいときに適切に動作するように修正されました。 (Andres Freund) (9.6)(9.5)(9.4)</li>
<p>
SAVEPOINTを使った更新の一部がロジカルデコーディング出力から抜け落ちることがありました。
</p>
<li>ロジカルWALデコーディングにおける不正ポインタの問題が修正されました。 (Stas Kelvich) (9.6)</li>
<li>共有メモリ割り当て要求を実際の huge pageサイズの倍数に丸めるようになりました。 (Tom Lane) (9.6)(9.5)(9.4)</li>
<p>
本修正は、典型的でないデフォルト huge page サイズをもつシステムで munmap() の起こりうる失敗を回避します。クラッシュリカバリの場合を除き、これまでも悪影響はログメッセージ以外ありませんでした。
</p>
<p>
プラットフォームが Linux の場合に対応した修正となります。
</p>
<li>libpq で SSLコンテキストを複数の接続に亘って共有しようと試みなくなりました。 (Heikki Linnakangas) (9.6)(9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
特に異なる接続に異なる SSLパラメータを使うときに、稀な場合で起きる様々な障害をもたらしていました。
</p>
<p>
予期せぬ SSL error (サーバ側ログとしては ERROR: could not accept SSL connectionなど) が発生することが報告されました。
</p>
<li>libpq の稀な場合のメモリリークが回避されました。 (Tom Lane) (9.6)(9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
PQreset() でエラー報告内容がメモリリークするケースが報告されました。関連するケースがいくつかあると見られます。
</p>
<li>pg_upgrade はライブラリがロード可能かを名前の長さ順にチェックするようになりました。 (Tom Lane) (9.6)(9.5)</li>
<p>
拡張モジュール間の依存問題を回避する簡易的な対策です。手続き言語、データ型、TRANSFORM (手続き言語とSQLデータ型の対応付け) を提供する拡張モジュールがあって、plpython、hstore、hstore_plplythonというモジュール名であるなら前者二つが先にロードされることが期待できます。
</p>
<li>インデックスアクセスメソッドを含む拡張モジュールに対してpg_upgrade が正しく動作するようになりました。 (Tom Lane) (9.6)</li>
<p>
サーバが ALTER EXTENSION ADD / DROP ACCESS METHOD に対応するように拡張されました。この機能はアクセスメソッドの動的作成に対応した当初のパッチに含まれているべきでしたが、見落とされていました。
</p>
<li>pg_upgrade のファイルのコピー、リンク、書換えの各段階でのエラー報告が改善されました。 (Tom Lane, Álvaro Herrera) (9.6)</li>
<p>
Windows 以外のプラットフォームでシステムからのメッセージがより適切にエラーメッセージに含まれるようになります。
</p>
<li>pg_dump が 7.4 よりも前バージョンのサーバで動作するように修正されました。 (Amit Langote, Tom Lane) (9.6)</li>
<p>
ラージオブジェクトの処理をする部分に修正が適用されています。
</p>
<li>pg_rewind に --source-server と --source-target を両指定することが禁止されました。 (Michael Banck) (9.6)(9.5)</li>
<p>
二つとも設定するのは無意味ですがエラーを出すようになっていませんでした。
</p>
<li>pg_rewind が元サーバのセッションで synchronous_commit を off にするようになりました。 (Michael Banck, Michael Paquier) (9.6)(9.5)</li>
<p>
これまでは、同期レプリケーションを使っているサーバをソースサーバに指定して、その同期レプリケーションが何らか理由で動作しない場合に、pg_rewind が一時テーブルを作るところで固まってしまっていました。
</p>
<li>pg_xlogdump で --follow オプションを使った場合、新たな WALセグメントファイルのオープンを再試行するようになりました。 (Magnus Hagander) (9.6)(9.5)(9.4)(9.3)</li>
<p>
これによりサーバの次セグメント作成の遅れに対応します。
</p>
<li>ロールバックされた更新の対象となっている壊れたタプルに対して、正しい TID を報告するように contrib/pg_visibility が修正されました。 (Tom Lane) (9.6)</li>
<li>PL/Python の並行ビルドが確実に成功するように、Makefile の依存関係が修正されました。 (Pavel Raiskup) (9.6)</li>
<li>タイムゾーンデータファイルが tzdata release 2016h に更新されました。 (9.6)(9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
パレスチナとトルコの夏時間法の変更、トルコとロシアのいくつかの地域の歴史的修正が適用されます。南極大陸、旧ソ連、スリランカのいくつかのタイムゾーンが数値による省略形に切り替えられました。
</p>
<p>
IANAタイムゾーンデータベースはこれまで（ほとんど使われない物も含めて）全てのタイムゾーンに文字による省略形を提供していました。現在、現実世界で英語の省略形として使われている形跡がないタイムゾーンについては数値による UTCオフセットの使用を優先する方針に転換する過程にあります。
</p>
<p>
少なくとも暫くの間、PostgreSQL はタイムスタンプの入力にそのような削除された省略形を受け入れる予定です。しかしながら、削除された省略形は、pg_timezone_namesビューにはあらわれなくなり、出力には使われなくなります。
</p>
<p>
本アップデートでは、AMT がアルメニア時間(UTC+4)という意味では使われなくなり、アマゾン時間(UTC-4)と解釈されるようになります。
</p>
<li>ビッグエンディアンのマシンにおける GINインデックス WALレコードの誤った作成が修正されました。 (Tom Lane) (9.5)(9.4)</li>
<p>
典型的な症状は WALリプレイに際して「unexpected GIN leaf action」が出ることです。
</p>
<li>SELECT FOR UPDATE/SHARE がその後に中止(ロールバック)したトランザクションに更新されたタプルを適切にロックするように修正されました。 (Álvaro Herrera) (9.5)(9.4)(9.3)</li>
<p>
9.5 以降では、SELECT はこのようなタプルを返すのに時々失敗していました。より古いバージョンでこの障害が起きることは証明されていませんが、同時更新を伴う場合で可能性があると考えられます。
</p>
<li>CTEスキャンを伴う EvalPlanQual の再チェックが修正されました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
再チェックでは常に CTE を行が返さないものとみていて、典型的には最近に更新された行の更新失敗をひき起こしました。
</p>
<p>
CTE (WITH句) を使って SELECT ... FOR UPDATE を実行する問い合わせで、並行する UPDATE 処理とのタイミングによっては、返るべき行が返らない障害が報告されています。
</p>
<li>INSERT ... ON CONFLICT による取り消しの際の、推測で挿入された TOASTタプルの削除が修正されました。 (Oskari Saarenmaa) (9.5)</li>
<p>
2つのトランザクションがほぼ同時に衝突するタプルを挿入しようとする競合状態で、挿入内容に TOASTフィールドが含まれている場合に、挿入できなかった方が以下のエラーを出していました。
</p>
<pre>ERROR:  attempted to delete invisible tuple
</pre>
</p>
<li>サブクエリでハッシュ集約からの前結果の不適切な重複が修正されました。 (Andrew Gierth) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
性能を改善するプランナの修正となります。これまで無駄な計算が生じていました。
</p>
<li>主キーやレプリカ識別(REPLICA IDENTITY)インデックスを伴うテーブルの大規模な UPDATE における、問い合わせ内のメモリリークが修正されました。 (Tom Lane) (9.5)(9.4)</li>
<li>EXPLAIN で測定されない時間をゼロと出力しないようになりました。 (Maksim Milyutin) (9.5)(9.4)(9.3)(9.2)</li>
<p>
いくつかのケースで計測対象外の項目についても欄があらわれ、その値がゼロになっていました。
</p>
<p>
「TIMING off」を指定しているのにトリガ関数実行時間が 0 で出力されたり、FORMAT が text 以外の時に track_io_timing = off で計測されないにもかかわらず「I/O Read Time: 0.000」「I/O Write Time: 0.000」が出力されたりしていました。
</p>
<li>VACUUM がテーブル切り捨てをするためにテーブル排他ロックを待っているときのタイムアウトの長さが修正されました。 (Simon Riggs) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
このタイムアウトは 50 ミリ秒のつもりが、実際には誤って 50 マイクロ秒になっていました。このため VACUUM がすぐにテーブル切り捨て（通常VACUUM でのファイルサイズ縮小）をあきらめてしまっていました。
</p>
<li>numeric型で受け入れられる値の人為的な制約が除去されました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
テキスト入力の numeric_in()、バイナリ入力の numeric_recv() の両方で修正されています。
</p>
<p>
これまで 指数記号を使ったとき、指数部を 1000 を上限としていたのは全く無意味であるため、格納形式上の制限（1e100000 を越える）までの数値が許可されるようになりました。
</p>
<p>
また、バイナリ入力の場合には数値の桁数が 1000 桁を越えた場合にも拒絶していましたが、これも修正されました。
</p>
<pre>(修正前の動作例)
db1=# SELECT 1.0e+1000::numeric; -- これはエラーにならない

db1=# SELECT repeat('1', 100000)::numeric; -- 指数形式でなければ問題ない

db1=# SELECT 1.0e+1001::numeric; -- 指数形式で指数部が 1000 を超えるとエラーになる
ERROR:  invalid input syntax for type numeric: "1.0e+1001"
LINE 1: SELECT 1.0e+1001::numeric;
             ^
</pre>
</p>
<li>短縮キーの利用を止めたときに起きうるソートの誤りが修正されました。 (Peter Geoghegan) (9.5)</li>
<p>
誤ったソート順序がもたらされる可能性があり、最悪の場合、壊れたBtreeインデックスが生じます。この場合 REINDEX が必要です。ただし、発生は非常に稀と考えられます。
</p>
<li>1GB を超える一時リレーションを切り捨てするときに起きるファイルデスクリプタのクローズ漏れが修正されました。 (Andres Freund) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
一時テーブルに対する VACUUM および ON COMMIT TRUNCATE 指定に基づく動作の時のみ影響があります。
</p>
<li>standby_mode を on にしてスタンドアローンバックエンドを起動することが禁止されました。 (Michael Paquier) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
WALデータを取り込む WALレシーバプロセスが無いので、そのように指定しても役に立ちません。また、スタンバイ動作が考慮されていないため誤動作をもたらしました。
</p>
<li>以前に使用したスロットを再利用するときに、レプリケーションスロット状態を適切に初期化するようになりました。 (Michael Paquier) (9.5)(9.4)</li>
<p>本障害で VACUUM がデッドタプルを除去するのを妨げるおそれがありました。
</p>
<li>動的共有メモリの制御セグメントID に、よりランダムな値を使うようになりました。 (Robert Haas, Tom Lane) (9.5)(9.4)</li>
<p>
これまで srandom() を呼ばずに random() から供給を受けていたため、同じ値が毎回選択されていました。比較的無害ですが、これは想定の動作ではありません。
</p>
<li>Windows において、動的共有メモリの制御セグメントの作成をaccess denied エラーの後、再試行するようになりました。 (Kyotaro Horiguchi, Amit Kapila) (9.5)(9.4)</li>
<p>
Windows は既存セグメントがあるとき、ときどき ERROR_ALREADY_EXISTS でなくERROR_ACCESS_DENIED を返します。これを回復不能エラーと判断していたため、PostgreSQL 起動に失敗していました。
</p>
<li>PL/pgSQL が int2vector型や oidvector型のパラメータとローカル変数で誤動作しないように修正されました。 (Tom Lane) (9.5)</li>
<p>
誤った応答やバックエンドクラッシュをひき起こす可能性があります。</p>
<pre>(正常動作例: 修正前バージョンでは誤応答やクラッシュが起きる)
db1=# CREATE FUNCTION f44(int2vector) RETURNS text LANGUAGE plpgsql
        AS $$ BEGIN RETURN $1::text; END;$$;
db1=# SELECT f44('1'::int2vector);
 f44
-----
 1
(1 row)
</pre>
<li>ecpg の --help と --version オプション が他のコマンドと一貫性をもった動作をするようになりました。 (Haribabu Kommi) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>pgbench の平均遅延の計算が修正されました。 (Fabien Coelho) (9.5)(9.4)</li>
<p>
スクリプト中で sleep コマンドがあるとき、あるいは、テスト実行期間を時間ではなくトランザクション数で指定しているとき、計算が誤っていました。
</p>
<li>pg_dump が範囲型を作る関数をダンプしないように修正されました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)</li>
<p>
範囲型を作る関数とは CREATE TYPE name AS RANGE で指定する関数のことです。--binary-upgrade のとき、拡張モジュールに属するこれら関数が誤ってダンプされていました。pg_upgrade での問題が報告されました。
</p>
<li>pg_dump で -C と --no-tablespaces を指定しているとき、CREATE DATABASE に TABLESPACE 句を付けないように修正されました。 (Tom Lane) (9.5)</li>
<li>pg_receivexlog がスロットなしで --synchronous を指定しているとき、正しく動作するように修正されました。 (Gabriele Bartolini) (9.5)</li>
<p>
スロットが無いとフラッシュ位置が報告されませんでした。
</p>
<li>pg_xlogdump が複数ページにわたる継続レコードで始まる WALファイルに対応するように修正されました。 (Pavan Deolasee) (9.5)(9.4)(9.3)</li>
<li>contrib/pg_buffercache が 256GB を超える shared_buffers のときに動作するように修正されました。 (KaiGai Kohei) (9.5)(9.4)</li>
<li>contrib/intarray の bench.pl で -e が指定された際に EXPLAIN 結果を捨てずに出力するように修正されました。 (Daniel Gustafsson) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>OpenSSL 1.1.0 がサポートされました。 (Heikki Linnakangas) (9.5)</li>
<li>拡張のテストで使えるように TAPテスト基盤が導入されました。 (Craig Ringer) (9.5)(9.4)</li>
<p>
ビルド時に --enable-tap-tests を指定すると、make install でPGXS が見つけられたものについて TAPテストのためのサポートPerlファイルがインストールされます。
</p>
<li>MSVC でのビルドで、クライアントのみのインストールに pg_recvlogical が含まれるようになりました。 (MauMau) (9.5)(9.4)</li>
<li>最近の Windows バージョンで追加されたタイムゾーン名を認識するように、Windows のタイムゾーン割り当てが更新されました。 (Michael Paquier) (9.5)(9.4)(9.3)(9.2)</li>
<li>廃止された動的なタイムゾーン省略形についてエラーが出るのを防ぐようになりました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
動的タイムゾーン省略形が参照されているタイムゾーンでどれにも一致しない場合、これをタイムゾーン名と等しいものとして扱います。これにより、IANA が彼らのタイムゾーンデータベースから省略形を削除したときの予期せぬエラーを回避します。
</p>
<li>ロジカルWALデコーディングでのバッファオーバランが修正されました。 (Tom Lane) (9.4)</li>
<p>
タプル更新レコードのロジカルデコーディングは 23バイト余計に読み取りました。これは通常無害ですが、非常に運が悪ければクラッシュをひき起こします。
</p>
</ol>
</p>
<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.1.23 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-1-23/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Thu, 11 Aug 2016 01:04:49 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.1]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=1762</guid>

					<description><![CDATA[このリリースは 9.1.22 からの修正リリース（2016年8月11日リリース）です。 9.1.x からのアップデートではダンプ、リストアは不要です。 また、9.1.16 より前のバージョンからアップデートを行う場合は  ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.1.22 からの修正リリース（2016年8月11日リリース）です。</p>
<p>9.1.x からのアップデートではダンプ、リストアは不要です。</p>
<p>また、9.1.16 より前のバージョンからアップデートを行う場合は <a href="/tech-blog/pgsql/9-1-16/">9.1.16 に関する技術情報</a> を参照してください。</p>
<p><span id="more-1762"></span></p>
<h3>PostgreSQL 9.1.22 から 9.1.23 への変更点</h3>
<p>9.5.4、9.4.9、9.3.14、9.2.18、9.1.23 の各バージョンが同時にリリースされており、 本ページでは共通の記載としています。 各修正項目が適用されるバージョン系列番号を 項目末尾に括弧書きで記載しています。<br />
<hr />
<ol>
<li>入れ子になった CASE-WHEN式の誤評価のおそれがあり、修正されました。 (Heikki Linnakangas, Michael Paquier, Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
他の CASE のテスト値の副式としてあらわれる CASE式では、自身のテスト値が null かどうかを誤ることがありました。
</p>
<p>
CASE式で使用される等価演算子を実装する SQL関数のインライン化により、そのSQL関数内で CASE式で呼ばれた関数に誤ったテスト値を渡すおそれがありました。テスト値が異なるデータ型である場合、クラッシュするかもしれず、更には、一部サーバメモリを露出させるために悪用されるかもしれません。これは CVE-2016-5423 として登録されています。
</p>
<p>
以下例は、副CASE式で 'it was bar!' になり、返し値は 'bar recognized'になるのが正しい動作です。
</p>
<pre>(入れ子CASEの障害動作例)

db=# CREATE FUNCTION vol(text) RETURNS text AS
       'begin return $1; end' LANGUAGE PLPGSQL VOLATILE;

db=# SELECT CASE
     (CASE vol('bar') WHEN 'foo' THEN 'it was foo!'
                      WHEN vol(null) THEN 'null input'
                      WHEN 'bar' THEN 'it was bar!' END)
     WHEN 'it was foo!' THEN 'foo recognized'
     WHEN 'it was bar!' THEN 'bar recognized'
     ELSE 'unrecognized' END;

     case
--------------
 unrecognized
(1 row)
</pre>
<p>
以下例は 'is not foo' が返るのが正しい動作です。定義した =演算子と inline_eq関数は、最後の SELECT文の CASE式を通して実行されます。
</p>
<pre>(インライン関数の = 演算子の障害動作例)

db=# CREATE DOMAIN foodomain AS text;
db=# CREATE FUNCTION volfoo(text) RETURNS foodomain AS
       'begin return $1::foodomain; end' LANGUAGE plpgsql VOLATILE;
db=# CREATE FUNCTION inline_eq(foodomain, foodomain) RETURNS boolean AS
       'SELECT CASE $2::text WHEN $1::text THEN true ELSE false END'
       LANGUAGE sql;
db=# CREATE OPERATOR = (procedure = inline_eq,
       leftarg = foodomain, rightarg = foodomain);

db=# SELECT CASE volfoo('bar')
            WHEN 'foo'::foodomain THEN 'is foo' ELSE 'is not foo' END;
  case
--------
 is foo
(1 row)
</pre>
<li>クライアントプログラムにおけるデータベース名とロール名に含まれる特殊文字の扱いが修正されました。 (Noah Misch, Nathan Bossart, Michael Paquier) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
多くのクライアントプログラムが、データベース名やロール名が "（ダブルクオート）や （バックスラッシュ）を含むことで、混乱をきたすことがありえました。
</p>
<p>
psql の connect と password において、2つ組のダブルクオートの扱いがドキュメント通りになるように修正されました。
</p>
<p>
さらに、psql の connect コマンドに -reuse-previous オプションが導入され、以前の接続のパラメータを再利用するかの明示的な制御ができるようになりました。従来はデータベース名が接続文字列のように見えるかで選択されていました。これは pg_dumpall で特殊文字を含むデータベース名の安全な処理を可能にします。
</p>
<p>
pg_dumpall は、改行文字(CR、LF)を含むデータベース名・ロール名の処理を拒絶するようになりました。将来はサーバ側でもこのような名前を拒絶するかもしれません。
</p>
<p>
作りこんだ特殊文字を含むオブジェクト名が、次に pg_dumpall や他のメンテナンス操作をするときにスーパーユーザ権限でコマンドを実行させるのに用いられるかもしれないため、これらはセキュリティ修正とみなされます。本件は CVE-2016-5424 として登録されています。
</p>
<li>入れ子の複合値に適用される IS NULL、IS NOT NULL の誤動作が修正されました。 (Andrew Gierth, Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
SQL標準では IS NULL は全ての要素が NULL である行値には TRUE を返すべきとしていますが、これは再帰的に適用することを意味しません。
</p>
<pre>(IS NULL のSQL標準仕様)
 ROW(NULL,NULL) IS NULL             → TRUE
 ROW(NULL, ROW(NULL, NULL)) IS NULL → FALSE
</pre>
<p>
PostgreSQL のエグゼキュータは上記の通りに作られていますが、プランナ最適化が働いて、以下のような誤った結果が生じていました。
</p>
<pre>(誤動作の例 - プラン時点で ROW(NULL,NULL) に置換済み)

=# EXPLAIN (VERBOSE) SELECT ROW(NULL, ROW(NULL, NULL)) IS NULL;
                      QUERY PLAN
-------------------------------------------------------
 Result  (cost=0.00..0.01 rows=1 width=0)
   Output: (ROW(NULL::unknown, NULL::unknown) IS NULL)
(2 rows)

=# SELECT ROW(NULL, ROW(NULL, NULL)) IS NULL;
 ?column?
----------
 t
</pre>
<p>
postgres_fdw によるリモート問い合わせでも同様の問題があり、修正されました。
</p>
<li>再帰 CTE (WITH RECURSIVE) 内で INSERT ... ON CONFLICT 構文を使うと、unrecognized node type エラーが出るのが修正されました。 (Peter Geoghegan) (9.5)</li>
<p>
以下のようにエラーが発生していました。
</p>
<pre>db=# CREATE TABLE foobar (id text PRIMARY KEY);

db=# WITH RECURSIVE upserted AS (
       INSERT INTO foobar (id) VALUES ('a')
       ON CONFLICT (id) DO NOTHING
       RETURNING id
       ) SELECT id FROM upserted;
ERROR:  XX000: unrecognized node type: 920
</pre>
<li>INSERT ... ON CONFLICT が、プランナの式の前処理フェーズで単純化されたインデックス式やインデックス述語を正常に照合するように修正されました。 (Tom Lane) (9.5)</li>
<p>
以下のような場合に、ON CONFLICT の conflict_target に対応したユニークインデックスや排他制約が無いと見なされて、エラーが発生していました。障害発生はデータ型や書き方に依存します。下記例では、bigint型のところがint型であれば、あるいは、0 を '0'::bigint と記述していれば発生しません。
</p>
<pre>db=# CREATE TABLE t5 (a bigint, b bigint);

db=# CREATE UNIQUE INDEX ON t5 (coalesce(a, 0), coalesce(b, 0));

db=# INSERT INTO t5 VALUES (1, 2)
       ON CONFLICT ((coalesce(a, 0)), (coalesce(b, 0))) DO NOTHING;
ERROR:  there is no unique or exclusion constraint matching the ON CONFLICT specification
</pre>
<li>INSERT ... ON CONFLICT命令で、ON CONSTRAINT で指定されていない方の排他制約に違反した場合の処理が修正されました。 (Tom Lane) (9.5)</li>
<p>
以下例のような場合が該当します。通常の制約違反になるのが正しい動作ですが、無限ループに入ってしまいます。
</p>
<pre>(エラー例)
db=# CREATE TABLE t6 (f1 int UNIQUE, f2 box, EXCLUDE USING gist(f2 WITH &amp;&amp;));
db=# INSERT INTO t6 VALUES (1, '((0,0),(1,1))');
INSERT 0 1

db=# INSERT INTO t6 VALUES (2, '((0,0),(1,2))')
       ON CONFLICT ON CONSTRAINT t6_f1_key DO NOTHING;
  → f2 の方の制約違反なのでエラーになるのが正しいが、無限ループで応答しない
</pre>
<li>INSERT ... ON CONFLICT が、対象テーブルが OID カラムにユニークインデックスを持っていた場合に失敗しないようになりました。 (Tom Lane) (9.5)</li>
<p>
これまでは該当の場合には、OIDカラムの制約に関係があっても無くても、INSERT ... ON CONFLICT が使用できませんでした。以下のようにエラーが発生します。
</p>
<pre>db=# CREATE TABLE t7 (id int UNIQUE) WITH """"OIDS;
db"""" =# CREATE UNIQUE INDEX ON t7 (oid);

db=# INSERT INTO t7 VALUES (1) ON CONFLICT (id) DO NOTHING;
ERROR:  system column in index

db=# INSERT INTO t7 VALUES (1) ON CONFLICT (oid) DO NOTHING;
ERROR:  system columns cannot be used in an ON CONFLICT clause
</pre>
<li>inet型、cidr型がコロン区切りフィールドが多すぎる IPv6アドレスを正しく拒絶するようになりました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
IPv6アドレスの表記は 128ビットを 16ビットごとにコロン(:)で区切るので最大でもコロンは 7つです。また、「::」が使えるのは一か所だけです。これら規則に違反してもエラーにならず「::/0」と解釈される場合がありました。
</p>
<pre>(誤動作の例)

db=# SELECT '99:99:99:99::99:99:99:99:99:99'::inet;
 inet
------
 ::/0
(1 row)

db=# SELECT '99:99:99:99::99:99:99:1::/118'::cidr;
 cidr
------
 ::/0
(1 row)
</pre>
<li>point ## lseg 演算子の実装である close_ps() 関数が NaN値を含む入力座標でクラッシュしてしまうのが防止されました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
上記演算子は右辺要素内の左辺要素への近接点を返すものです。これまでクラッシュしていたケースでは NULL が返るようになります。
</p>
<pre>(演算子の通常動作とクラッシュ例)

=# SELECT '(1.5,1.5)'::point ## '(0,0),(0,3)'::lseg;
 ?column?
----------
 (0,1.5)
(1 row)

=# SELECT 'NaN,NaN'::point ## '(Nan,0),(0,NaN)'::lseg;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
</pre>
<li>一貫性に欠けた値が渡された場合に pg_get_expr() 関数がクラッシュする可能性が回避されました。 (Michael Paquier, Thomas Munro) (9.5)(9.4)(9.3)</li>
<p>
以下の障害例が報告されました。
</p>
<pre>db=# CREATE TABLE t10 (id int primary key, c1 int NOT NULL, c2 int);
db=# CREATE INDEX idx10 ON t10 (c1) WHERE (c2 = 100);

db=# SELECT pg_get_expr(i.indpred, i.indexrelid) FROM pg_index i;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
</pre>
<p>
pg_get_expr() は pg_dump やシステムビュー定義内で使われる関数であって、アプリケーションやデータベース管理者が直接使うことはほとんどありません。
</p>
<li>to_number() で幾つかの 1バイトのバッファ超過読み込みが修正されました。 (Peter Eisentraut) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
幾つかの場合に to_number() 関数が入力文字列から1文字多く読み取りしていました。入力データがメモリ末尾に隣接している場合には、僅かながらクラッシュの可能性があります。
</p>
<li>WITH NO DATA が指定されたときには、CREATE MATERIALIZED VIEW またはCREATE TABLE AS に含まれている問い合わせに対して プランナを実行しないようになりました。 (Michael Paquier, Tom Lane) (9.5)(9.4)(9.3)</li>
<p>
これは不要なエラー状況を回避します。例えば、STABLE な関数が参照するテーブルがマテリアライズドビューを作成した時点では未だ無い、といった場合です。
</p>
<li>heap_update() を通る高コストパスにおいて、安全でない中間状態を回避するようになりました。 (Masahiko Sawada, Andres Freund) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
これまで該当ケースにおいては、XMAX をセットして対象タプルをロックするけれど、その操作を WAL書き出しをしませんでした。そのため、ページ変更がバッファ溢れでディスクに書かれて、続いてタプル更新が完了する前にクラッシュが生じると、データ不整合の危険がありました。
</p>
<li>行ロック操作の WALリプレイでのヒントビット更新が修正されました。 (Andres Freund) (9.5)(9.4)(9.3)</li>
<p>
本障害の影響として、コミット前の準備されたトランザクションにより保持された行ロックがクラッシュ後の再起動で適用に失敗するおそれがあることが知られています。
</p>
<li>SERIALIZABLE または REPEATABLE READモードで SELECT ... FOR KEY SHARE による行ロックを取得するときに、不要な直列化失敗エラーの発生を回避するようになりました。 (Álvaro Herrera) (9.5)(9.4)(9.3)</li>
<p>
FOR KEY SHARE 行ロックは外部キー制約を持つテーブルの更新で暗黙に取得されます。以下の場合にエラーが発生していましたが、修正後は発生しなくなります。
</p>
<pre>(テスト用のテーブルを作成)
db=# CREATE TABLE t15a (id int PRIMARY KEY, uid int, name text);
db=# CREATE TABLE t15b (id int PRIMARY KEY, d date);
db=# ALTER TABLE t15a ADD FOREIGN KEY (uid) REFERENCES t15b (id);
db=# INSERT INTO t15b VALUES (1, now());
db=# INSERT INTO t15a VALUES (1, 1, 'one');

(セッションその1)
db=# START TRANSACTION ISOLATION LEVEL REPEATABLE READ;
db=# UPDATE t15a SET name = 'update1', uid = 1 WHERE id = 1;

                      (セッションその2)
                      db=# START TRANSACTION ISOLATION LEVEL REPEATABLE READ;
                      db=# UPDATE t15b SET d = now() WHERE id = 1;
                      db=# COMMIT;

db=# UPDATE t15a SET name = 'update2', uid = 1 WHERE id = 1;
ERROR:  could not serialize access due to concurrent update
CONTEXT:  SQL statement "SELECT 1 FROM ONLY "public"."t15b" x WHERE "id" OPERATOR(pg_catalog.=) $1 FOR KEY SHARE OF x"
</pre>
<li>エグゼキュータにおいて、拡張されたデータムがプランノードから返るとき、それが確実にリードオンリーであるように修正されました。 (Tom Lane) (9.5)</li>
<p>
データム(Datum)とは SQLデータ型の値の受け渡しに使われる実装内部データ型です。本修正で、下位プランノードの結果が上位ノードの複数個所で参照される場合に、失敗するのを回避します。PostgreSQL本体に関する限り PL/pgSQL関数から返される配列値のみ、危険があります。ただし、拡張モジュールでは拡張されたデータムを他に使っているかもしれません。
</p>
<p>
本障害で「ERROR: cache lookup failed for type 0」(数値 0 の部分は様々)、または、クラッシュが生じる可能性があります。
</p>
<li>postgres -C で指定した設定変数が NULL文字列値を持つときのクラッシュが回避されました。 (Michael Paquier) (9.5)(9.4)(9.3)(9.2)</li>
<p>
OS X でクラッシュが報告されていました。
</p>
<li>wal senderプロセスにおいて、意図せず WAL receiver 応答を待機する動作が防止されました。 (Kyotaro Horiguchi) (9.5)</li>
<li>ロジカルデコーディングで巨大なサブトランザクションが一部あるいは全部欠ける可能性があり、修正されました。 (Petru-Florin Mihancea) (9.5)(9.4)</li>
<li>ロジカルデコーディングで、サブトランザクションに実質的な変更を含まず、外側のトランザクションが変更を含んでいる場合に、デコードに失敗するのが修正されました。 (Marko Tiikkaja, Andrew Gierth) (9.5)(9.4)</li>
<p>
以下のようなトランザクションで、外側トランザクションでの INSERT がデコードされませんでした。
</p>
<pre>db=# BEGIN;
db=# INSERT INTO xact_test VALUES ('main-txn');
db=# SAVEPOINT foo;
db=# SELECT 1 FROM xact_test FOR UPDATE ;
db=# COMMIT;
</pre>
<li>バックエンドが共有カタログの最新の統計を確実に見るようになりました。 (Tom Lane) (9.5)(9.4)(9.3)</li>
<p>
統計情報コレクタは、通常バックエンドからの要求後、共有カタログについて統計ファイルの更新に失敗していました。この問題は、自動VACUUMランチャーが定期的に更新を生じさせる要求を出すため、部分的に隠されていました。しかし、自動VACUUM を無効にして露見しました。
</p>
<p>
共有カタログにはデータベース単位でなく、インスタンス単位の情報が記録されます。
</p>
<li>複数バックエンドが近接して共に更新を要求したとき、統計ファイルの冗長な書き込みを回避するようになりました。 (Tom Lane, Tomas Vondra) (9.5)(9.4)(9.3)</li>
<li>VACUUM でトランザクションID の消費を回避するようになりました。 (Alexander Korotkov) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
一部ケースで VACUUM は不要に XID を現在トランザクションに割り当てました。通常これはごく僅かですが、XID周回の上限に直面したとき、XID周回対策の VACUUM でさらに多くの XID を消費するのは甚だ良くない動作です。
</p>
<li>9.3 より前のバージョンから pg_upgrade でアップグレードしたインスタンスで、マルチトランザクションID の VACUUM処理にて失敗する可能性があり、修正されました。 (Andrew Gierth, Álvaro Herrera) (9.5)(9.4)(9.3)</li>
<p>
本障害のよくある症状は以下のようなエラーです。
</p>
<pre>ERROR:  MultiXactId NNN has not been created yet -- apparent wraparound.
</pre>
<li>カラムリストを指定した手動 ANALYZE ではテーブルの changes_since_analyze カウンタをリセットしなくなりました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
ANALYZEコマンドは以下のように特定テーブルの特定カラムを指定して実行することができます。
</p>
<pre>=# ANALYZE t25 (col1, col2);
</pre>
<p>
このような一部のカラムのみの ANALYZE を行なっている場合に、他のカラムのための自動ANALYZE が阻害されるべきではありません。
</p>
<li>ANALYZE で多数のヌルエントリがある、ユニークかほぼユニークなカラムに対する n_distinct の過大評価が修正されました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
各 null が、それぞれ別の値である(distinct)とカウントされており、いくつかのクエリ形式では、深刻なプランナの予測間違いに繋がります。
</p>
<li>autovacuum で、同じ共有カタログに対して複数のワーカが処理開始するのを避けるようになりました。 (Álvaro Herrera) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
通常、vacuum は長くかからないので、これは大きな問題になりません。しかし稀に深刻に肥大化したカタログのケースでは、ひとつを除きすべてのワーカが、他のテーブルで有益な作業をせずに、無駄に待機する結果になります。
</p>
<li>B-Tree のマーク/リストア処理のバグが修正されました。 (Kevin Grittner) (9.5)</li>
<p>
この間違いは、マージジョインの内側ノードが B-Treeインデックススキャンの時に、誤った結合結果やアサーション失敗をひき起こす原因となっていました。
</p>
<li>B-Tree インデックスページの削除が中断された時、二重にバッファロック解放が行われるのを回避するようになりました。 (Tom Lane) (9.5)(9.4)</li>
<p>
この間違いは、壊れたB-Treeインデックスを伴ういくつかのケースで VACUUM完了を妨げます。VACUUM で以下のエラーが出るケースが報告されています。
</p>
<pre>ERROR:  lock main NNNNN is not held
</pre>
<li>巨大な(shared_buffers を越える)ハッシュインデックスの作成が修正されました。 (Tom Lane) (9.5)</li>
<p>
巨大なインデックスの際に使われるコードパスに不具合があり、誤ったハッシュ値がインデックスに挿入されます。そのため、初期構築後にインデックスに挿入されたタプルを除き、その後のインデックスサーチは常に失敗しました。
</p>
<p>
エラーが出るのではなく、本来見つかるべき行が見つからない結果になります。
</p>
<li>GiSTインデックス作成で幾何データ型カラムの成分に NaN値を含む場合に無限ループになる可能性が防止されました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)</li>
<p>
box型に対する CREATE INDEX ... USING gist ... コマンドが応答しない動作が、報告されています。
</p>
<li>contrib/btree_gistインデックスの intervalカラムを使った、近傍検索(ORDER BY distance) インデックススキャンで、クラッシュする可能性があり、修正されました。 (Peter Geoghegan) (9.5)</li>
<li>BRINインデックスエントリを更新する時、BRINタプルの追加に失敗するケースの PANIC が修正されました。 (Álvaro Herrera) (9.5)</li>
<p>
以下のように PANIC が生じて、マスタプロセスの停止または再起動が生じていました。
</p>
<pre>WARNING:  specified item offset is too large
PANIC:  failed to add BRIN tuple
</pre>
<li>バックグラウンドワーカの停止時に、バックグラウンドワーカを制御するバックエンドプロセスがクラッシュする可能性あり、修正されました。 (Dmitry Ivanov) (9.5)</li>
<li>PL/pgSQL で IMPORT FOREIGN SCHEMA コマンド内の INTO 句の扱いが修正されました。 (Tom Lane) (9.5)</li>
<p>
これまで PL/pgSQL内では、INTO 付きの IMPORT FOREIGN SCHEMA が動作しませんでした。
</p>
<li>contrib/btree_gin が bigint型の最小値を正しく扱えるように修正されました。 (Peter Eisentraut) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>libpq が将来のサーババージョンを正しく解釈できるようになりました。 (Peter Eisentraut) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
9.6 以降のリリースでは、サーババージョンが現在の 3 パートから、2パートに変更される計画です。PQserverVersion() がその様な時にも正しい値を返すようになりました。
</p>
<li>"unsigned long long" 型の配列要素に関する ecpg コードが修正されました。 (Michael Meskes) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>pg_dump の -c と -C オプションで、不要な CREATE SCHEMA public コマンドが出力されないようになりました。 (David Johnston, Tom Lane) (9.5)(9.4)(9.3)(9.2)</li>
<li>パラレル pg_dump と pg_restore で SIGTERM や Ctrl-C の扱いが改善されました。 (Tom Lane) (9.5)(9.4)(9.3)</li>
<p>
ワーカプロセスが速やかに終了するようになり、また、CREATE INDEX の様な長時間実行されるケースに対応するため、クエリキャンセル要求が接続されたバックエンドに送られるようになりました。
</p>
<li>パラレル pg_dump と pg_restore のエラー報告が修正されました。 (Tom Lane) (9.5)(9.4)(9.3)</li>
<p>
これまでは、pg_dump や pg_restore のワーカプロセスからのエラーメッセージがユーザのコンソールに出力されないことがありました。
</p>
<p>
メッセージはマスタプロセスを通して伝達されますが、いくつかデッドロックするシナリオがあり、マスタプロセスのメッセージ伝搬を妨げていました。代わりとして単純に stderr にすべてを出力します。いくつかのケースでは、重複するメッセージが出力されることになります。例えばすべてのワーカがサーバシャットダウンを報告します。
</p>
<li>Windows でのパラレル pg_dump や pg_restore で、エラー後は適切に停止するようになりました。 (Kyotaro Horiguchi) (9.5)(9.4)(9.3)</li>
<p>
以前までは、エラーは報告するけれど、ユーザが手動で停止するまで居座っていました。
</p>
<li>スタンバイサーバに対するパラレル pg_dump が適切に失敗するようになりました。 (Magnus Hagander) (9.5)</li>
<p>
--no-synchronized-snapshots が指定されていない場合、この使い方はサポートされませんが、エラーが適切に処理されていませんでした。
</p>
<li>zlib サポートなしでビルドされた pg_dump の振る舞いが改善されました。 (Kyotaro Horiguchi) (9.5)(9.4)(9.3)</li>
<p>
パラレルダンプが正しく動作しなかったり、無意味な警告が発せられるケースがありました。圧縮を必要としないオプションであるにも拘らず、以下メッセージが出る場合が報告されています。
</p>
<pre>pg_dump: [archiver] WARNING: requested compression not available in this installation -- archive will be uncompressed
pg_dump: [parallel archiver] not built with zlib support
</pre>
<li>pg_basebackup は -Z 0 で圧縮なし指定と受け取るようになりました。 (Fujii Masao) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
これまでは無効な圧縮レベルであるとして、「pg_basebackup: invalid compression level ...」というエラーになっていました。
</p>
<li>パラレルメイクで AIX の共有ライブラリを安全にビルドできるようにmakefile のルールを修正しました。 (Noah Misch) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>TAP テストと MSVC スクリプトが、ビルドディレクトリパス名に空白が含まれていても、動くようになりました。 (Michael Paquier, Kyotaro Horiguchi) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>statement_timeout と lock_timeout の報告が、より予測可能になりました。 (Tom Lane) (9.5)(9.4)(9.3)</li>
<p>
負荷の高いマシンでは、ステートメントタイムアウトが先に発生したのに、ロックタイムアウトが報告されるため、リグレッションテストが時々失敗していました。
</p>
<li>デンマーク語とウェールズ語ロケールでのレグレッションテストが安全になりました。 (Jeff Janes, Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
これらのロケールで通常と異なるソートルールの引金になるテストデータが修正されました。
</p>
<li>タイムゾーンコードのコピーが IANA の tzcode release 2016c に合わせて更新されました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
これはタイムゾーンデータファイルの将来の変更を見越した対応で必要になります。また通常と異なるタイムゾーンの対処で、稀にあるバグを修正しています。
</p>
<li>タイムゾーンデータが tzdata release 2016f に更新されました。 (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
ケメロヴォとノヴォシビルスクの夏時間の変更と、アゼルバイジャン、ベラルーシ、およびモロッコの歴史的な修正が含まれます。
</p>
<li>hot standby クエリが VACUUM FREEZE でキャンセルされないようになりました。 (Simon Riggs, Álvaro Herrera) (9.4)(9.3)(9.2)(9.1)</li>
<p>
アイドルではないマスタサーバ上の VACUUM FREEZE は、スタンバイサーバのクエリを不必要にキャンセルすることがありました。
</p>
<li>pg_ctl start -w のタイムアウトが古いヒューリスティックな方法に戻りました。 (Tom Lane) (9.1)</li>
<p>
9.1.20 から採用された新しい方法は silent_mode が有効な時にうまく動きません。そのため古い方法に戻されました。
</p>
</ol>
</p>
<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.1.22 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-1-22/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Thu, 12 May 2016 01:04:57 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.1]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=1746</guid>

					<description><![CDATA[このリリースは 9.1.21 からの修正リリース（2016年5月12日リリース）です。 9.1.x からのアップデートではダンプ、リストアは不要です。 また、9.1.16 より前のバージョンからアップデートを行う場合は  ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.1.21 からの修正リリース（2016年5月12日リリース）です。</p>
<p>9.1.x からのアップデートではダンプ、リストアは不要です。</p>
<p>また、9.1.16 より前のバージョンからアップデートを行う場合は <a href="/tech-blog/pgsql/9-1-16/">9.1.16 に関する技術情報</a> を参照してください。</p>
<p><span id="more-1746"></span></p>
<h3>PostgreSQL 9.1.21 から 9.1.22 への変更点</h3>
<p>9.5.3、9.4.8、9.3.13、9.2.17、9.1.22 の各バージョンが同時にリリースされており、<br />
本ページでは共通の記載としています。 各修正項目が適用されるバージョン系列番号を<br />
項目末尾に括弧書きで記載しています。<br />
<hr />
<ol class="technology">
<li>OpenSSLのエラーキューを既にクリアされているとみなすのでなく、OpenSSL呼び出し前にクリアするようになりました。また、確実に呼出し後にクリアしておくようにしました。  (Peter Geoghegan, Dave Vitek, Peter Eisentraut) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
この変更は単一プロセス内に OpenSSLを使った複数の接続があって、エラーキューをクリアするときの規則が一貫していない場合の問題を防止します。
</p>
<p>
具体的には、クライアントアプリケーションが、OpenSSL の PHP、Python、または Ruby によるラッパーを使った SSL接続と並行して、libpq で SSL接続を使用した場合に、障害が報告されました。OpenSSL を使用する命令で予想外のエラーが発生します。
</p>
<p>
サーバ内でも、拡張モジュールが SSL接続をしにいく場合には同様の問題が起きる可能性があります。
</p>
<li>LEFT JOIN の右手側の中の FULL JOIN で、プランナエラー「ERROR:  failed to build any N-way joins」が出るのが修正されました。  (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
メッセージ中の N-way の N には実際には数字が入ります。
</p>
<p>
「LEFT JOIN の右手側の中の FULL JOIN」とは以下のような形状の SQL を意味します。
</p>
<pre>
SELECT * FROM
    (SELECT 1 AS id) AS xx
  LEFT JOIN
    (SELECT 1 AS id) AS a1 FULL JOIN (SELECT 1 AS id) AS yy ON (a1.id = yy.id)
  ON (xx.id = coalesce(yy.id));
</pre>
<li>多段の入れ子ループ内における等価クラステストの誤った扱いが修正されました。  (Tom Lane) (9.5)(9.4)(9.3)(9.2)</li>
<p>
X.X = Y.Y = Z.Z のような 3つ以上からなる値の等価クラスが与えられたとき、同値であるようにするために必要な検査の一部を、プランナが無視する可能性があり、出力される結合結果が WHERE句を満たさないことがありえました。
</p>
<p>
様々な理由により実際には誤ったプランは滅多に選択されません。そのため、本障害は長い間みつかりませんでした。
</p>
<p>
以下のようなプラン形状のときに該当します。
</p>
<pre>
Nested Loop
  -&gt;  Scan X
  -&gt;  Nested Loop
    -&gt;  Scan Y
    -&gt;  Scan Z
          Filter: Z.Z = X.X
</pre>
<li>operator_precedence_warning = on のときの稀なパーサエラーが修正されました。  (Tom Lane) (9.5)</li>
<p>
以下に発生例を示します。
</p>
<pre>
db1=# SELECT (ARRAY[])::text[];
 array
-------
 {}
(1 row)

db1=# SET operator_precedence_warning TO on;
SET

db1=# SELECT (ARRAY[])::text[];
ERROR:  cannot determine type of empty array

db1=# SELECT ARRAY[]::text[];
 array
-------
 {}
(1 row)
</pre>
<li>GINインデックススキャンでの問い合わせ処理内のメモリリークが修正されました。  (Julien Rouhaud) (9.5)(9.4)</li>
<li>GINインデックス挿入において、問い合わせ処理内のメモリリークと、インデックス破損の可能性が修正されました。  (Tom Lane) (9.5) (9.4)</li>
<p>
このメモリリークは単純な問い合わせにおいては通常は大きな量になりません。しかし、大きな maintenance_work_mem 値で巨大な GINインデックスを作成するときには、かなりの量になることがありえます。
</p>
<li>to_timestamp() における整形コード TH、th、Y,YYY に誤動作の可能性があり、修正されました。  (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
これらが入力文字列の終端を超えた参照をして、以降の整形コードでゴミが読み取られるおそれがありました。
</p>
<p>
また、本障害をデータ露出させる攻撃に使うことは極めて困難と判断されました。
</p>
<li>「値 演算子 ANY ( 配列 )」という構造の「配列」が副問い合わせである場合について、ルールとビューのダンプが修正されました。  (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
実行するとエラーになる誤った定義がダンプ出力されていました。以下に障害動作例を示します。
</p>
<pre>
(正常に実行できる SQL)
db1=# SELECT 'c'::text = ANY
        ((SELECT array['a','b','c']::text[])::text[]) c1;
 c1
----
 t
(1 row)

db1=# CREATE VIEW v1 AS
        SELECT 'c'::text = ANY
          ((SELECT array['a','b','c']::text[])::text[]) c1;

(ビュー定義して、定義を出力すると変形している)
db1=# SELECT pg_get_viewdef('v1', true);
                                             pg_get_viewdef                     
--------------------------------------------------------------------------------------------------------
  SELECT 'c'::text = ANY ((( SELECT ARRAY['a'::text, 'b'::text, 'c'::text] AS "array"))) AS c1;
(1 row)

(これを再度定義に適用するとエラーになる)
db1=# CREATE VIEW v1_restore AS 
        SELECT 'c'::text = ANY
          ((( SELECT ARRAY['a'::text, 'b'::text, 'c'::text] AS "array"))) AS c1;
ERROR:  operator does not exist: text = text[]
</pre>
<li>ALTER SYSTEM パラメータ値で改行が禁止されました  (Tom Lane) (9.5)(9.4)</li>
<p>
設定ファイルのパーサは文字列リテラル中に改行が含まれることに対応していません。したがって、ALTER SYSTEM でも禁止すべきでした。
</p>
<li>ALTER TABLE ... REPLICA IDENTITY USING INDEX で、OID のインデックスが指定された場合でも適切に動作するように修正されました。  (David Rowley) (9.5)(9.4)</li>
<p>
WITH OIDS を指定したテーブルの OID列のインデックスを指定した場合に、クラッシュや奇妙なメッセージが生じることがありました。
</p>
<li>テーブルスペースのシンボリックリンクを削除するのに失敗した後に起きる可能性があった誤動作を回避するようになりました。  (Tom Lane) (9.5)</li>
<li>アラインメントにうるさいプラットフォーム上でのロジカルデコーディングのクラッシュが修正されました。  (Tom Lane, Andres Freund) (9.5)(9.4)</li>
<p>
トランザクションが溢れてディスクに書き出されるだけの大きさであり、かつ、トランザクション中で主キーが変更される場合に限って、障害が発生します。
</p>
<li>walsenderプロセスが停止しようとしている間、receiverからのフィードバックのためのリクエストが繰り返されるのを回避するようになりました。  (Nick Cleaton) (9.5)(9.4)</li>
<li>pg_regress が PGCTLTIMEOUT環境変数で指定された起動タイムアウトを使うようになりました。  (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
一つ前のマイナーリリースで pg_ctl が PGCTLTIMEOUT を参照するようになっていて、これと一貫性を持たせるための変更です。遅いマシンでのテストを容易にします。
</p>
<li>pg_upgrade が、拡張モジュールの一つだけの演算子クラスを含む演算子族の所属を正しくリストアできるように、修正されました。  (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
このような場合、演算子族は新しいデータベースにリストアされますが、拡張モジュールの一部であるとマークされませんでした。即座には悪影響は生じませんが、後に pg_dump を実行して、それをリストアする時に（無害ですが）エラーが生じます。
</p>
<li>pg_upgrade が、新クラスタの TOAST規則が旧クラスタと異なるときに失敗しないように、修正されました。  (Tom Lane) (9.5)(9.4)(9.3)</li>
<p>
pg_upgrade には、あるテーブルに旧バージョンでは TOASTテーブルが無く、新PostgreSQLバージョンではそのテーブルは TOASTテーブルを持つべきという場合を扱う処理実装が含まれていました。
</p>
<p>
この実装が壊れていたため、このような場合には何もしないように修正されました。実際のところ、アップグレード後のクラスタで旧バージョンの規則にしたがってテーブルに付随する TOASTテーブルが無かったとしても、特に問題ないと考えられます。
</p>
<li>IBM の XLCコンパイラを使ったときの PPCアーキテクチャむけアトミック操作が修正されました。  (Noah Misch) (9.5)</li>
<li>--disable-spinlocks を指定したビルドから使われる SysVセマフォの数を減らしました。  (Tom Lane) (9.5)(9.4)(9.3)(9.2)</li>
<li>NetBSD のライブラリ関数との衝突を避けるため、内部関数 strtoi() が strtoint() に名前変更されました。  (Thomas Munro) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>Windows における bind()、listen() からのエラー報告が修正されました。  (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
ソケットエラーについて Windows と Unix のエラー番号変換が拡充されました。これまで「could not bind IPv4 socket: No error」といったエラーが出ていたケースで有益なエラーメッセージが得られるようになります。
</p>
<li>Visual Studio むけビルドスクリプトで、コンパイラ出力の verbosity設定（冗長さ）を detailed から normal に減らしました。  (Christian Ullrich) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>Visual Studio 2015 でのビルドをサポートしました。  (Michael Paquier, Petr Jel&iacute;nek) (9.5)</li>
<p>
VS2015 でビルドされたプログラムは、Windows Vista より以前の Windows では動作しません。(locale 判定の方法が変更されたため)
</p>
<li>Visual Studio 2013 で正しく動作するように putenv() を修正しました。  (Michael Paquier) (9.5)(9.4)(9.3)</li>
<li>Windows の FormatMessage() 関数の安全でない可能性がある利用を避けるようにしました。 (Christian Ullrich) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>FORMAT_MESSAGE_IGNORE_INSERTS フラグを適切な箇所で使います。既知のバグはありませんが、注意するのは良いことです。
</p>
<li>タイムゾーンデータが tzdata release 2016d に更新されました。   (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
ロシアとベネズエラの夏時間の変更。新しいゾーン名 Europe/Kirov と Asia/Tomsk があり、これらの地域は、隣接する地域とは異なるタイムゾーンの歴史を持っています。
</p>
<li>9.4系でのメモリバリアコードの変更を 9.2 と 9.3 にバックポートしました。 (Tom Lane) (9.3)(9.2)</li>
<p>
これらの変更は 9.4以前のブランチでは元々は不要でした。しかし最近、バリアコードを正しく動作させる修正がバックパッチされました。IA64(iccを使った時), HPPA, Alpha のプラットフォームが影響を受けます。
</p>
</ol>
</p>
<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.1.21 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-1-21/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Thu, 31 Mar 2016 01:04:14 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.1]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=1712</guid>

					<description><![CDATA[このリリースは 9.1.20 からの修正リリース（2016年3月31日リリース）です。 9.1.x からのアップデートではダンプ、リストアは不要です。 また、9.1.16 より前のバージョンからアップデートを行う場合は  ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.1.20 からの修正リリース（2016年3月31日リリース）です。</p>
<p>9.1.x からのアップデートではダンプ、リストアは不要です。</p>
<p>また、9.1.16 より前のバージョンからアップデートを行う場合は <a href="/tech-blog/pgsql/9-1-16/">9.1.16 に関する技術情報</a> を参照してください。</p>
<p><span id="more-1712"></span></p>
<h3>PostgreSQL 9.1.20 から 9.1.21 への変更点</h3>
<p>9.5.2、9.4.7、9.3.12、9.2.16、9.1.21 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。 各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<p>Cロケール以外をお使いの場合、本バージョンへのアップデート後に REINDEX が必要になります。<br />
<hr />
<ol>
<li>Cロケール以外での文字列ソートに短縮キーが使えなくなりました。  (Robert Haas) (9.5)</li>
<p>
PostgreSQL 9.5 から、strcoll() に代えて strxfrm() を使うことで文字列比較を高速化する仕組みが導入されました。現在ほとんどのバージョンの glibc で、一部ロケールにおいて strxfrm()の実装が誤っていて、比較結果が strcoll() と一致しないことが明らかになりました。この問題がよく把握されるまで、この最適化はCロケール以外では無効となりました（Cロケールの場合、strcoll() も strxfrm() 使わないので安全です）。
</p>
<p>
この変更は、文字列データ型に対するソートのみならず B-treeインデックス上の並び順にも影響します。バージョンアップ後に REINDEX が必要です。
</p>
<p>
ここで影響のあるロケールの網羅的なリストを示すことはできません。Cロケールは安全です。en_US のような英語ベースのロケールは問題ないと見られます。de_DE など、その他の一般的なロケールは、ほとんどのglibc バージョンで影響があります。
</p>
<li>キャッシュされたプランで行セキュリティ状態を適切に保つようになりました。  (Stephen Frost) (9.5)</li>
<p>
2つ以上のロールで問い合わせが実行されるセッションでは、プランキャッシュが他のロールで生成されたプランを誤って再利用する可能性があり、これにより、行単位セキュリティが使われているとき、間違ったポリシーセットが適用されるおそれがありました。(CVE-2016-2193)
</p>
<li>contrib/pageinspect拡張モジュールの新たな関数に管理者ユーザであるかのチェックが追加されました。  (Andreas Seltenreich) (9.5)</li>
<p>
bytea型データを解析する pageinspect拡張モジュールの大部分の関数は、一般ユーザからの呼び出しを許可していませんが、brin_page_type() とbrin_metapage_info() ではチェックが漏れていました。
</p>
<p>
作りこまれた byteaデータをこれらの関数に渡すことで、サーバをクラッシュさせたり、わずかなサーバメモリを露出させることができるかもしれません。(CVE-2016-3065)
</p>
<li>インデックス付けされた ROW() の比較について修正されました。  (Simon Riggs) (9.5)</li>
<p>
ここで ROW() とは複数カラムの1行データを指します。ROW(1, 100, 'A') のように記述しますが、単に (1, 100, 'A') のようにも書きます。
</p>
<p>
複数カラムに条件を付けて検索した場合に、インデックス順序が一部だけ適合するような複合インデックスが使われると誤った結果が返ることがありました。以下に例を示します。
</p>
<pre>
db=# CREATE TABLE t1 AS
       SELECT (10 + random() * 10)::int AS c1,
            round((10 + random() * 10)::numeric, 5) AS c2
         FROM generate_series(1, 10000) g;

db=# SELECT count(*) FROM (
       SELECT * FROM t1 WHERE (c1, c2) &lt; (20, 11)
         ORDER BY c1 DESC, c2) v;

db=# CREATE INDEX idx_t1 ON t1 USING btree (c1 DESC, c2 ASC);

 → インデックス作成後、再度、上記の SELECT を行うと結果が異なることがある
</pre>
<p>
9.5.0 で導入された最適化が原因です。より良い修正方法が得られるまで、ひとまず当該の最適化を除去するものとなりました。
</p>
<li>インデックス付けされた ROW() の比較において、NULLインデックス項目の誤った扱いが修正されました。  (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
「 ROW(a, b) &gt; ROW('x', 'y') 」のような行比較をするインデックス検索が、bカラムで NULLに当たるとそこで止まってしまいました。そのため誤った結果が返る可能性があります。
</p>
<p>
以下に問題発生例を示します。本例末尾の SELECT文は、"Seq Scan" 以外の全てのインデックスを使うプランタイプにおいて誤った出力になります。
</p>
<pre>
(間に b=NULL の行が1000行挟まっているデータを作成)
db=# CREATE TABLE t2 (id int primary key, a text, b text);
db=# INSERT INTO t2 VALUES (0, 'a', 'b');
db=# INSERT INTO t2 SELECT g, 'a', NULL FROM generate_series(1, 1000) AS g;
db=# INSERT INTO t2 VALUES (1001, 'z', 'y');

(正しい出力)
db=# SELECT a, b FROM t2 WHERE (a, b) &gt; ('a', 'a') ORDER BY a, b;
 a | b
---+---
 a | b
 z | y
(2 rows)

(インデックスが使われて、誤った出力)
db=# CREATE INDEX idx_ab_t2 ON t2 (a, b);
db=# SELECT a, b FROM t2 WHERE (a, b) &gt; ('a', 'a') ORDER BY a, b;
 a | b
---+---
 a | b
(1 row)
</pre>
<li>前後に適切な fsync() 実行の無いファイル名変更によるデータ損失シナリオを回避するように修正されました。  (Michael Paquier, Tomas Vondra, Andres Freund) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
電源断など OS/ハードウェアが異常停止した際にデータが壊れるおそれがありました。ただし、発生の可能性は低いといえます。
</p>
<li>SELECT ... FOR UPDATE/SHARE を行い、かつ、ロックを必要としないリレーションも含むクエリにおいて、同時に変更された行の再チェックを行うときの振る舞いが修正されました。  (Tom Lane) (9.5)</li>
<p>
ロックされないリレーションに由来する行が、再チェックの間、全て NULL であるかのように誤って扱われていました。このことで、更新された行が WHERE条件を満たさなくなったと誤って判断されたり、誤って NULL が出力される可能性がありました。
</p>
<p>
以下の再現例が報告されています。
</p>
<pre>
db=# CREATE TABLE t3 (id int primary key, v text);
db=# CREATE TABLE t4 (id int primary key, v text,
       CONSTRAINT fk_id FOREIGN KEY (id) REFERENCES t3 (id));
db=# INSERT INTO t3 VALUES (1, 'A');
db=# INSERT INTO t4 VALUES (1, 'B');

(接続その1)             (接続その2)
db=# BEGIN;
db=# UPDATE t3 SET v = 'A' WHERE id = 1;
db=#
                        db=# pset null *null*
                        db=# SELECT t3.v AS t3v, 
                               (SELECT t4.v FROM t4 WHERE t3.id = t4.id) AS t4v
                               FROM t3 WHERE t3.id = 1 FOR UPDATE OF t3;
                        ...ロック待ち...
db=# COMMIT;
                        ...ロック待ち解除後に応答に NULL が混入...
                          t3v |  t4v
                         -----+--------
                          A   | *null*
                         (1 row)
</pre>
<li>json_to_record() 関数の障害が修正されました。  (Tom Lane) (9.5)(9.4)</li>
<p>
入力オブジェクトがサブオブジェクトを含み、そのフィールド名が要求された出力カラム名のどれかに一致していた場合に、エラーになったり、出力が不正になったりしていました。
</p>
<p>
以下に例を示します。
</p>
<pre>
db=# SELECT * FROM json_to_record('{"a":0,"b":{"c":1,"a":2}}'::json)
                   AS t(a int , b text);
ERROR:  invalid input syntax for integer: "{"c":1,"a":2"

正しい出力は以下です。
 a |       b
---+---------------
 0 | {"c":1,"a":2}
(1 row)

db=# pset null *null*
db=# SELECT t.c FROM json_to_record('{"a":1,"b":{"c":16,"d":2},"x":8}'::json)
                     AS t(a int, b json, c text, x int);
    c
---------
 {"c":16
(1 row)

正しい出力は以下です。サブオブジェクトは取得できないのが正常です。
   c
--------
 *null*
(1 row)
</pre>
<li>jsonb_object() 関数を 2引数で空配列にて呼び出した場合について修正されました。  (Michael Paquier, Andrew Dunstan) (9.5)</li>
<p>
以下のようなエラーが発生していました。
</p>
<pre>
db=# SELECT jsonb_object('{}'::text[], '{}'::text[]);
ERROR:  unknown type of jsonb container

正しい出力は以下。空のJSONBオブジェクトが返る。
 jsonb_object
--------------
 {}
(1 row)
</pre>
<li>jsonb_set() 関数にて、パス配列の要素が配列添え字として使う整数に変換されるときの誤動作が修正されました。  (Michael Paquier) (9.5)</li>
<p>
与える添え字用の値によっては不適切なエラーが出ることがあります。また、最悪の場合にはクラッシュをひき起こす可能性があります。
</p>
<pre>
(正常動作の場合)
db=# SELECT jsonb_set('{"a":[1],"b":[]}'::jsonb, '{"a",1}'::text[], '100');
       jsonb_set
-----------------------
 {"a": [1, 100], "b": []}
(1 row)

db=# SELECT jsonb_set('{"a":[1],"b":[]}'::jsonb, '{"a",9999}'::text[], '100');
ERROR:  path element at the position 2 is not an integer
</pre>
<li>to_char() のテンプレートパターン「OF」による負のタイムゾーンオフセットの誤った整形が修正されました。  (Thomas Munro, Tom Lane) (9.5)(9.4)</li>
<pre>
(9.5.2 実行例)
db=# SET timezone = '00:30';
SET
db=# SELECT to_char(now(), 'OF');
 to_char
---------
 -00:30
(1 row)

(9.5.1 実行例)
db=# SET timezone = '00:30';
SET
db=# SELECT to_char(now(), 'OF');
 to_char
---------
 +00:30
(1 row)

(9.4.6 実行例)
db=# SET timezone = '00:30';
SET
db=# SELECT to_char(now(), 'OF');
 to_char
---------
 +00:-30
(1 row)
</pre>
<li>INSERT ... ON CONFLICT による待機について誤ったログ出力の可能性があり、修正されました。  (Peter Geoghegan) (9.5)</li>
<p>
原因となる制約が無いにも拘らず、排他制約のために待ちが生じたとログ出力されていました。
</p>
<p>
log_lock_waits = on を設定した時のログで CONTEXT: に以下のように出力されます。
</p>
<pre>
LOG:  process 12345 acquired ShareLock on transaction 1234 after 12345.678 ms
CONTEXT: while checking exclusion constraint on tuple (1,2) in relation "t3"
</pre>
<li>リカバリが一貫性のある状態に達するまで、recovery_min_apply_delay パラメータを無視するようになりました。  (Michael Paquier) (9.5)(9.4)</li>
<p>
これまでスタンバイサーバは、データベースを有効な状態にするために必要とされるWALの初期部分を再生するときであっても、recovery_min_apply_delay 設定に対応して WALレコード適用を遅延していました。
</p>
<p>
スタンバイサーバは一貫性のある状態に到達するまで使えないため、この動作は役に立たないと判断されました。
</p>
<li>サーバのスタートアップ中、pg_subtrans が XID周回に近い場合について正しく処理するように修正されました。  (Jeff Janes) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
上記の「スタートアップ中」は、リカバリ中やスタンバイサーバ稼動中の状態が含まれます。
</p>
<p>
pg_subtrans/ 以下にファイルが大量に作られる現象が報告されています。
</p>
<li>ロジカルデコーディングにおけるいくつかの障害が修正されました。  (Andres Freund) (9.5)(9.4)</li>
<p>
問題ケースには以下が含まれます。
</p>
<p>
テーブルに指定された REPLICA IDENTITY が FULL であって変更タプル群が 1ページよりも大きい場合にアサート失敗を、またアサート無しのビルドで何らかの不正動作を、引き起こします。
</p>
<p>
ディスクへのスプールを要するほどに大きいトランザクション内でのプライマリキーを変更する UPDATE で新旧データが入れ替わってしまいました。
</p>
<p>
不正なエラー「ERROR: subxact logged without previous toplevel record」が発生することがありました。
</p>
<p>
9.5.x で誤ったトランザクションのコミット時刻が報告されました。
</p>
<li>入れ子になったセキュリティバリアビューについて、外側のビューが相関サブクエリを含むWHERE句を持つときのプランナの誤りが修正されました。  (Dean Rasheed) (9.5)(9.4)</li>
<p>
以下の v2 のような形のビュー定義が該当します。
</p>
<pre>
CREATE VIEW v1 WITH (security_barrier = true) AS
  SELECT * FROM t1 WHERE (c1 &gt; 0)
  WITH CHECK OPTION;

CREATE VIEW v2 WITH (security_barrier = true) AS
  SELECT * FROM v1 WHERE EXISTS (SELECT 1 FROM t2 WHERE t2.c1 = v1.c1)
  WITH CHECK OPTION;
</pre>
<p>
ビューの参照時に予期せぬエラー「ERROR:  XX000: plan should not reference subplan's variable」がでるケースが報告されました。
</p>
<li>GINインデックス検索でメモリリークが修正されました。  (Tom Lane) (9.5)</li>
<li>ロケール機能の実装コードが稀な状況でメモリ二重解放によりクラッシュすることがあり、修正されました。  (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>全文検索の ispell辞書むけ接辞ファイル(AffFile)の読み取りが修正されました。  (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
大文字小文字変換でバイト長が変わる文字が含まれている接辞ファイルに対して動作が狂うかもしれませんでした。例えばトルコ語で UTF8 のロケールにおける「I」が該当します。
</p>
<li>ispell辞書ファイルの読み取りで sscanf() を使わないようになりました。  (Artur Zakirov) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
これにより Mac OS X を含む FreeBSD派生のプラットフォームにおける移植性の問題を回避します。
</p>
<li>IBM xlcコンパイラでの PPC 上のアトミック操作コードが修正されました。  (Noah Misch) (9.5)</li>
<p>
この誤りは該当プラットフォーム上で稀に同時操作の失敗をもたらします。
</p>
<li>Visual Studio 2013 でビルドした PostgreSQL が、AVX2-capable CPU を使ったサーバ上の古いバージョンの Windows (7 sp1 / 2008R2 sp1より古い) でクラッシュするのを回避するように修正されました。  (Christian Ullrich) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
修正は Microsoft が修正しないと表明している Visual Studio 2013 のランタイムライブラリのバグを回避するものです。
</p>
<li>psql のタブ補完がマルチバイト文字を適切に扱えるように修正されました。  (Kyotaro Horiguchi, Robert Haas) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>SECURITY LABEL に対する psql のタブ補完が修正されました。  (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
SECURITY LABEL の後 TAB を押すとクラッシュしたり、あるいは、不適切なキーワードが提示される可能性がありました。
</p>
<li>pg_ctl がコマンドラインに指定がなくとも PGCTLTIMEOUT環境変数による待機タイムアウトを受け入れるようになりました。  (Noah Misch) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
本環境変数の参照は本マイナーバージョンで追加された動作となります。
</p>
<li>pg_ctl にて Windowsサービス状態の検査が修正されました。  (Manuel Mathar) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
前のマイナーリリースで、ログメッセージを Windowsイベントログに出すかどうか適切に判断する修正が試みられましたが、逆さまに検査していました。
</p>
<li>pgbench が -C と -M prepared オプションの組み合わせを正しく扱えるように修正されました。  (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
これまでは当該オプション組み合わせでは動作しませんでした。
</p>
<li>pg_upgrade で、新データディレクトリが旧データディレクトリ内にあるとき削除スクリプトの作成を省略するようになりました。  (Bruce Momjian) (9.5)(9.4)(9.3)</li>
<p>
上記ケースで盲目的にこのスクリプトを適用すると結果として新データディレクトリが失われてしまいます。
</p>
<li>PL/Perl で空の PostgreSQL配列を空の Perl配列に適切に変換できるように修正されました。  (Alex Hunsaker) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>PL/Python で有効な Python識別子でない関数名をうまく処理できるようになりました。  (Jim Nasby) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>contrib/pgstattuple の pgstatindex()関数が返す統計について、いくつかの誤りが修正されました。  (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
デッドページが有効なページと報告されていました。インデックスメタページがインデックスサイズに含まれていませんでした。ルートページが internal_pages に含まれていませんでした。ドキュメントもいくつか修正されました。
</p>
<p>
本修正前後のマイナーバージョンでの結果と数値比較をする場合には注意が必要となります。
</p>
<li>psed が Perl本体で提供されなくなったため、MSVCビルドで psed への依存が除かれました。  (Michael Paquier, Andrew Dunstan) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>タイムゾーンデータファイルが tzdata release 2016c に更新されました。   (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
アゼルバイジャン、チリ、ハイチ、パレスチナ、ロシア（アルタイ、アストラハン、キーロフ、サハリン、ウリヤノフスク地域）の夏時間法の変更、加えて、リトアニア、モルドバ、ロシア（カリーニングラード、サマラ、ヴォルゴグラード）の歴史的修正が含まれます。
</p>
</ol>
</p>
<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.1.20 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-1-20/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Thu, 11 Feb 2016 01:04:08 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.1]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=1694</guid>

					<description><![CDATA[このリリースは 9.1.19 からの修正リリース（2016年2月11日リリース）です。 9.1.x からのアップデートではダンプ、リストアは不要です。 また、9.1.16 より前のバージョンからアップデートを行う場合は  ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.1.19 からの修正リリース（2016年2月11日リリース）です。</p>
<p>9.1.x からのアップデートではダンプ、リストアは不要です。</p>
<p>また、9.1.16 より前のバージョンからアップデートを行う場合は <a href="/tech-blog/pgsql/9-1-16/">9.1.16 に関する技術情報</a> を参照してください。</p>
<p><span id="more-1694"></span></p>
<h3>PostgreSQL 9.1.19 から 9.1.20 への変更点</h3>
<p>9.5.1、9.4.6、9.3.11、9.2.15、9.1.20 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。 各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<hr />
<ol>
<li>正規表現での無限ループやバッファオーバーランの問題が修正されました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
非常に大きな文字範囲のブラケット式で、無限ループになったり、メモリのオーバーライトが起こっていました。本問題は CVE-2016-0773 として登録されています。
</p>
<pre>(障害発生する例)
SELECT regexp_matches('a', '[x0-x7fffffff]', 'i');
</pre>
<li>ハッシュ結合で内側リレーションの一部タプルがまれに結合で欠ける場合があり、修正されました。 (Tomas Vondra, Tom Lane) (9.5)</li>
<li>グループ化セットが使われる時は HAVING 句のプッシュダウンはされないようになりました。 (Andrew Gierth) (9.5)</li>
<li>ON CONFLICT構文の WHERE句の SQL文再構成について、修正されました。 (Peter Geoghegan) (9.5)</li>
<p>
一部のケースで ON ONFLICT .. WHERE を含むルール定義の出力が正しくなく、ダンプ／リストアに失敗する可能性があります。</p>
<li>log_line_prefix 設定におけるエスケープ %h、%r を log_connections 設定によるメッセージにも機能するようにしました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
これまで %h と %r は新たなセッションが確立した後にしか出力されませんでした。
</p>
<pre>(9.5.0 で log_line_prefix = ' [%h/%r] '、log_connections = on のログ例)
 [/] LOG:  connection received: host=127.0.0.1 port=42424
 [127.0.0.1/127.0.0.1(42424)] LOG:  connection authorized: user=postgres database=db1
 [127.0.0.1/127.0.0.1(42424)] ERROR:  syntax error at or near "x" at character 1
 [127.0.0.1/127.0.0.1(42424)] STATEMENT:  x;
</pre>
<li>SSPI認証でトークンハンドルのリーク（クローズ漏れ）が修正されました。 (Christian Ullrich) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>psql det コマンドでのパターン引数の解釈が修正されました。 (Reece Hart) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
スキーマ修飾付きかもしれないパターンに対して他の d コマンドが行うのと同様の動作となります。
</p>
<pre>(dt だとスキーマ名だけ指定してもマッチしません)
db1=# dt scm1
No matching relations found.

db1=# dt scm1.*
        List of relations
 Schema | Name | Type  |  Owner
--------+------+-------+----------
 hoge   | t1   | table | postgres
(1 row)

(det は、これまで例外的な動作でした)
db1=# det scm1
 List of foreign tables
 Schema | Table | Server
--------+-------+--------
 scm1   | ft1   | srv1
(1 row)
</pre>
<li>Windows における pg_ctl でサービス状態を確認して、ログメッセージの出力先を決めるようになりました。 (Michael Paquier) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
これまで pg_ctl から出力されるメッセージをリダイレクションで取得できない問題がありました。
</p>
<li>pg_dump が拡張モジュールに属するデータベースオブジェクトを処理するときの例外的なケースの障害がいくつか修正されました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>pg_dump におけるドメイン名の不適切なクオート付けが修正されました。 (Elvis Pranskevichus) (9.5)</li>
<p>
クオートを重複して付ける動作がありました。
</p>
<li>pg_dump がビューのトリガにそのルールの後に処理される必要があると印づけするようになり、パラレルpg_restore での失敗の可能性が予防されました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>pgbench でスクリプトに指定された除算や剰余演算子の評価における例外的なオーバーフロー条件での浮動小数点例外が防止されました。 (Fabien Coelho, Michael Paquier) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>9.3.x 以前のサーバに接続するときに pg_receivexlog が出力する無意味で混乱を招く警告メッセージが抑止されました。 (Marco Nenciarini) (9.5)</li>
<p>
9.3.x 以前のサーバは IDENTIFY_SYSTEM コマンドに対応していないために、「could not identify system: ...」というメッセージが出ていました。
</p>
<li>plpython2 と plpython3 を両方使うときのダンプ読み込みの問題を回避するようになりました。 (Tom Lane) (9.5)(9.4)(9.3)(9.2)</li>
<p>
(複数バージョンの libpython は安全に並行使用できませんが)同一セッションでなければ、原則として両バージョンの PL/Python を同一データベースで使用可能です。しかしながら、pg_restore と pg_upgrade はこの同一セッションの制約に抵触することがあります。これを PL/Python が読み込むコードをチェックするタイミングを変えることで回避しています。
</p>
<li>PL/Python の回帰テストが Python 3.5 で通るようになりました。 (Peter Eisentraut) (9.5)(9.4)(9.3)(9.2)</li>
<li>ある種の PL/Javaパラメータがスーパーユーザ以外から設定できてしまうのが防止されました。 (Noah Misch) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
この変更は PL/Java のセキュリティ障害(CVE-2016-0766)を軽減します。PL/Java は PostgreSQL本体には含まれませんが、本修正によりカスタム設定パラメータ pljava.classpath は、superuserコンテキストに設定されます。
</p>
<li>ecpgで提供されるヘッダファイルが、プリプロセッサ命令行にコメントを含まないように修正されました。 (Michael Meskes) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>hstore拡張モジュールの hstore_to_json_loose() 関数で、値を JSON数値に変換可能であるかの判定が修正されました。 (Tom Lane) (9.5)(9.4)(9.3)</li>
<p>
これまで本関数では構文的に不正な JSON を出力することがありました。以下の「2016-01-01」部分は「"2016-01-01"」と出力されるべきです。
</p>
<pre>(修正前の挙動)
db1=# SELECT hstore_to_json_loose(hstore('abc', '2016-01-01'));
 hstore_to_json_loose
----------------------
 {"abc": 2016-01-01}
(1 row)
</pre>
<li>postgres_fdw 拡張モジュールで、更新命令の AFTER ROW トリガーまたはRETURNING 式で tableoid を使う場合の障害が修正されました。 (Etsuro Fujita, Robert Haas) (9.5)(9.4)</li>
<p>
上記の場合にこれまで外部テーブルの tableoid カラム値として正しくない値が返っていました。
</p>
<li>実装上の定数 NAMEDATALEN (識別子の最大長) とMAX_LEVENSHTEIN_STRLEN (レーベンシュタイン距離計算における最大長)との間で NAMEDATALEN &lt;= MAX_LEVENSHTEIN_STRLEN という限定が除かれました。 (Robert Haas, Tom Lane) (9.5)</li>
<li>ワイルドカードでリンカに与えられるファイル名を固定順にすることで、ビルド出力の再現性が改善されました。 (Christoph Berg) (9.5)(9.4)(9.3)</li>
<p>
同じ条件で生成された実行ファイルにビットレベルでの差異が生じるのを防ぎます。
</p>
<li>MSVCビルドで dynloader.h がインストールされるヘッダファイルに含まれるようになりました。 (Bruce Momjian, Michael Paquier) (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<li>タイムゾーンデータファイルが tzdata release 2016a に更新されました。 (9.5)(9.4)(9.3)(9.2)(9.1)</li>
<p>
ケイマン諸島、メトラカトラ、ザバイカリエ地方(Zabaykalsky Krai) の夏時間法が変更され、パキスタンの歴史的な訂正が加わりました。
</p>
<li>json_path_ops 演算子クラスの GIN インデックスにおける一貫性に欠けたハッシュ計算が修正されました。 (Tom Lane) (9.4)</li>
<p>
同じ入れ子レベルにスカラとサブオブジェクトの両方を含む jsonb 値を処理するとき、見つかるべき項目が見つからないことがありえました。本修正を適用するには、アップグレード後に該当のインデックスを REINDEX する必要があります。
</p>
<p>
json_path_ops 演算子クラスは jsonb型に対する "@&gt;" 演算子に GINインデックスを適用するのに使われます。
</p>
<li>postmaster.pid ファイルが削除されたなら imediateシャットダウンを行うようになりました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<p>
PostgreSQL のマスタープロセスは postmaster.pid ファイルが在り、自身の PID が書かれているかを毎分確認し、無かったり PID が違った場合には immediate シャットダウンをするようになりました。
</p>
<p>
リリース情報に明記されていませんが、PostgreSQL 9.5.0 では既にそのようになっています。
</p>
<li>SERIALIZABLEトランザクション隔離モードで、INSERT時の競合状態のために直列化例外が見逃されることがあり、修正されました。 (Kevin Grittner, Thomas Munro) (9.4)(9.3)(9.2)(9.1)</li>
<p>
ごく限定されたタイミングでの同時実行で発生し、エラーを出すべきところで直列化されていない結果が返される動作となります。
</p>
<li>UNLOGGEDテーブルに対して ALTER TABLE ... SET TABLESPACE を実行したとき、適切なWALレコードが出力されない障害が修正されました。 (Michael Paquier, Andres Freund) (9.4)(9.3)(9.2)(9.1)</li>
<p>
テーブルのデータについては WAL出力対象外であるとしても、テーブルスペース移動は WAL出力すべきでした。そうでないと、スタンバイサーバが昇格したときにアクセス不能になります。
</p>
<li>クラッシュリカバリの最後に UNLOGGED なテーブル・インデックスが初期化されない可能性があり、修正されました。 (Andres Freund, Michael Paquier) (9.4)(9.3)(9.2)(9.1)</li>
<p>
よくある症状として、スタンバイを昇格させた後に以下のエラーが出ます。
</p>
<pre>ERROR:  index "..." contains unexpected zero page at block 0
</pre>
<li>wal sender のスロットが再使用時に完全に再初期化されるようになりました。 (Magnus Hagander) (9.4)(9.3)</li>
<p>
ここでのスロットは wal sender プロセスのための共有メモリ上のデータ構造であって、pg_create_physical_replication_slot 関数で作る物理レプリケーションスロットとは別物です。
</p>
<li>ALTER TABLE ... ALTER COLUMN TYPE が CHECK制約を適切に継承するように改修されました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<p>
親テーブルでカラムデータ型を変更すると当該カラムに対する CHECK制約の継承関係が壊れてしまいます。また、以下の奇妙なエラーが生じていました。
</p>
<pre>db1=# ALTER TABLE parenttable DROP CONSTRAINT parentconstraint_1;
ERROR:  relation 23456 has non-inherited constraint "parentconstraint_1"
</pre>
<li>REASSIGN OWNED コマンドが複合型の所有者も変更するように修正されました。 (Álvaro Herrera) (9.4)(9.3)(9.2)(9.1)</li>
<li>REASSIGN OWNED コマンドおよび ALTER ... OWNER コマンドが、データ型、外部データラッパ、外部サーバの所有者変更にあたって、適切にアクセス制御リストを更新するように修正されました。 (Bruce Momjian, Álvaro Herrera) (9.4)(9.3)(9.2)(9.1)</li>
<p>
所有者だけ変えて、アクセス制御リストは更新しない動作がありました。
</p>
<li>REASSIGN OWNED コマンドが外部ユーザマッピング（ユーザマップ）を無視するように変更されました。 (Álvaro Herrera) (9.4)(9.3)(9.2)(9.1)</li>
<p>
以下のような奇妙なエラーが出るケースが報告されていて、これを回避します。
</p>
<pre>ERROR: unexpected classid 1418 SQL state: XX000"
</pre>
<li>更新可能ビューむけの問い合わせ書換えの後にクラッシュする可能性があり、修正されました。 (Stephen Frost) (9.4)(9.3)</li>
<p>
キャッシュを参照する部分が更新処理を含む場合には安全ではありませんでした。
</p>
<li>LATERAL参照の扱いについてプランナが修正されました。 (Tom Lane) (9.4)(9.3)</li>
<p>
例外的な場合に以下のエラーが生じることがありました。
</p>
<pre> ERROR: failed to build any N-way joins
 (N-way の N には 2-way など数字が入る)

 ERROR: could not devise a query plan
</pre>
<li>インデックス内部の統計情報が古い場合に、GINインデックススキャンの粗悪なプランナコスト見積もりが生じるのを防ぐように修正されました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<li>GINインデックスのプランナコスト見積りが、インデックスアドバイザプラグインによる仮定のインデックスに対して改善されました。 (Julien Rouhaud) (9.4)(9.3)(9.2)(9.1)</li>
<p>
実在しないGINインデックスには内部統計情報が無いため、ダミーの代替データを用意する必要があり、これまでは不十分な実装でした。
</p>
<li>EXPLAIN とルールのダンプで重複しないテーブル別名の生成が高速化されました。また、生成される別名が確実に最大識別子長を超えないように修正ました。 (Tom Lane) (9.4)(9.3)</li>
<li>ROW() や VALUES() 内の行変数のダンプが修正されました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<p>
以下のようなビュー定義に対して、ダンプ出力が実際には適用できない内容になっていました。
</p>
<pre>(修正前の動作)
db1=# CREATE TABLE t2 (c1 int, c2 int);
db1=# CREATE TYPE nestedcomposite AS (c1c2 t2);
db1=# CREATE VIEW v1 AS SELECT ROW(t2)::nestedcomposite FROM t2;
db1=# SELECT pg_get_viewdef('v1', true);
               pg_get_viewdef
---------------------------------------------
  SELECT ROW(t2.*)::nestedcomposite AS "row"+
    FROM t2;
(1 row)

(上記のビュー定義 SELECT は正しくない、実行するとエラーになる)
db1=# SELECT ROW(t2.*)::nestedcomposite AS "row" FROM t2;
ERROR:  cannot cast type record to nestedcomposite

(以下が正しい)
db1=# SELECT pg_get_viewdef('v1', true);
                 pg_get_viewdef
-------------------------------------------------
  SELECT ROW(t2.*::t2)::nestedcomposite AS "row"+
    FROM t2;
(1 row)
</pre>
<li>dete型、timestamp型の -infinity値を、json型、jsonb型に変換するとき、+infinity になってしまう障害が修正されました。 (Tom Lane) (9.4)</li>
<pre>(修正前の誤った振る舞い例)
db1=# SELECT to_json('-Infinity'::date);
  to_json
------------
 "infinity"
(1 row)
</pre>
<li>numeric型データの除算で内部オーバーフローが生じる可能性があり、修正されました。 (Dean Rasheed) (9.4)(9.3)(9.2)(9.1)</li>
<li>正規表現で先行検索制約の制限が無視される誤りがあり、修正されました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<p>
マニュアル記載では、先行検索制約には、後方参照（1、2 など）を含むことが許されておらず、また、先行検索制約の中の括弧は常に捕捉されないとされていますが、これらの仕様に反する動作がありました。
</p>
<pre>(修正前動作／括弧を加えた 2番目の SQL も 1番目と同じくエラーになるのが正しい)
db1=# SELECT 'xyz' ~ 'x(w)(?=1)';
ERROR:  invalid regular expression: invalid backreference number

db1=# SELECT 'xyz' ~ 'x(w)(?=(1))';
 ?column?
----------
 t
(1 row)

(修正前動作／括弧を加えると NULL が捕捉されていた)
db1=# SELECT regexp_matches('abcfoo','(abc)(?=foo)');
 regexp_matches
----------------
 {abc}
(1 row)

db1=# SELECT regexp_matches('abcfoo','(abc)(?=((foo)))');
 regexp_matches
----------------
 {abc,NULL}
(1 row)
</pre>
<li>先行参照制約が含まれるとき、正規表現のインデックススキャン範囲への変換で不正確な範囲が生じる可能性があり、修正されました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<p>
インデックスが利用される場合に不正な検索結果が返る可能性がありました。
</p>
<pre>(修正前の動作／正しくは「(v &gt;= 'abcd'::text) AND (v &lt; 'abce'::text)」)
db1=# explain (costs off) SELECT * FROM t1 WHERE v ~ '^abcd(x|(?=ww)q)';
                          QUERY PLAN
--------------------------------------------------------------
 Index Scan using t1_v_idx on t1
   Index Cond: ((v &gt;= 'abcdx'::text) AND (v &lt; 'abcdy'::text))
   Filter: (v ~ '^abcd(x|(?=ww)q)'::text)
(3 rows)

(正しくは以下が返るとして、インデックススキャンでは id=5 の行が欠けることになる)
db1=# SELECT * FROM t1 WHERE v ~ '^abcd(x|(?=ww)q)';
 id |    v
----+---------
  5 | abcdqBB
  2 | abcdx
(2 rows)
</pre>
<li>正規表現のコンパイラが ^、$、先行参照制約のループを扱えるように修正されました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<p>
これらを扱えるようにセキュリティ障害 CVE-2007-4772 の修正が以前（7.4.19 など) に適用されていましたが、それは不十分なものでした。</p>
<pre>(以下の正規表現は無限ループやキャンセル時のクラッシュを引き起こしていました)
db1=# SELECT 'a' ~ '(^$)*';
 ?column?
----------
 t
(1 row)

db1=# SELECT 'dd x' ~ '(^(?!aa)(?!bb)(?!cc))+';
 ?column?
----------
 t
(1 row)
</pre>
<li>正規表現のコンパイラにおいてメモリ利用の計算が改善されました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<p>
これまで途方もない時間とメモリを要していたいくつかの場合について、「ERROR: invalid regular expression: regular expression is too complex」を出すようになりました。
</p>
<p>
これまでも似た意味で「ERROR: invalid regular expression: nfa has too many states」を出すことはありました。メッセージは前述のものに統合されています。
</p>
<li>正規表現のコンパイラの性能が改善されました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<li>Windowsにおいて、共有メモリを必要としない子プロセスで共有メモリマッピングハンドルを確実にクローズするようになりました。 (Tom Lane, Amit Kapila) (9.4)(9.3)(9.2)(9.1)</li>
<p>
この誤りは、logging_collector = on のとき、バックエンドクラッシュ後の自動再起動におけるリカバリの失敗を引き起こしていました。
</p>
<li>Windows のノンブロッキングモードでソケットの EOF を検知するのに失敗する可能性があり、修正されました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<p>
修正対象の 9.4.x 以前の各バージョンで問題が起きるか明らかではありませんが、起きていたとすれば、その症状は walsender プロセスが接続は失われているのに際限なく待つというものであるはずです。
</p>
<p>
9.5.x では既に修正済みです。
</p>
<li>psql で端末ウィンドウのサイズが変更されたとき、確実に libreadline のスクリーンサイズの認識が更新されるようになりました。 (Merlin Moncure) (9.4)(9.3)(9.2)(9.1)</li>
<p>
これまでは libreadline は問い合わせ出力中にウィンドウがリサイズされても気づかず、その後での複数行にわたる問い合わせの入力で奇妙な振る舞いをひき起こしていました。
</p>
<li>psql にて、これまでの接続が Unixドメインソケット経由であってc コマンドに新ホスト名と同ユーザ名を指定した場合に、クラッシュする可能性があり、修正されました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<li>pg_ctl start -w で子プロセス状態の検査をヒューリスティックに頼らず直接行うようになりました。 (Tom Lane, Michael Paquier) (9.4)(9.3)(9.2)(9.1)</li>
<p>
これまで pg_ctl は新たなマスタープロセスは常に 5秒以内に postmaster.pidを作るであろうという仮説に依存していました。これは高負荷システムでは失敗する可能性があり、「could not start server」という誤った報告をひき起こします。
</p>
<p>
Windows 以外では、本修正で、pg_ctl start -w を他の PostgreSQL起動コマンドの直後に実行したときに確実に失敗するようにもなります。これまでは最初のコマンドから 2秒以内に実行したときは (既存のプロセスが自身で起動したプロセスと見做されて) 成功と報告されました。
</p>
<li>pg_ctl start -w で接続試験にワイルドカードのリッスンアドレスを使おうとしないように修正されました。 (Kondo Yuta) (9.4)(9.3)(9.2)(9.1)</li>
<p>
pg_ctl は PostgreSQLサーバプロセスの起動確認にて、listen_addresses に 0.0.0.0 や :: が指定されていると、これらの値をそのままアドレスとして使用しますが、Windows では失敗します。それぞれ代わりに 127.0.0.1、::1 を使うべきでした。
</p>
<p>
Windows 以外では pg_ctl は Unixドメイン接続を使うので問題となりませんでした。
</p>
<li>pg_dump と pg_basebackup で、8GB を超える tarアーカイブ要素を扱うため、GNU 慣例が採用されました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<p>
tarフォーマットの POSIX標準では 8GB を超える tarアーカイブの要素を許可していませんが、ほとんどの近代的な tar の実装ではこれを可能とする拡張をサポートしています。
</p>
<p>
本修正で、pg_dump -Ft において 8GB 以上のテーブルが、また、pg_baesbackup -Ft において 8GB 以上のファイルが扱えるようになりました。これまでは 4GB から 8GB の間のサイズの要素についても、一部プラットフォームでは失敗し、リカバリできない問題がありました。
</p>
<li>pg_dump でリレーションのオプション値が確実に適切にクオートされるようになりました。 (Kouhei Sutou, Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<p>
ここでのリレーションのオプション値とは、テーブル、インデックス、ビューの定義に WITH (options) で与えられるものを指します。システムカタログの pg_class.reloptions に定義が格納されます。
</p>
<p>
これまで、オプション値がシンプルな識別子や数値でない場合にダンプ/リロードにて pg_dump による CREATE文の構文エラーで失敗していました。
</p>
<p>
PostgreSQL本体でサポートされているオプション値では問題ありませんが、拡張モジュールによるオプション値で問題が発生しました。
</p>
<li>パラレル pg_dump でパスワードプロンプトが繰り返し出るのが防止されました。 (Zeus Kronion) (9.4)(9.3)</li>
<li>Windows における pg_upgrade のファイルコピーでエラーを適切に扱うようになりました。 (Bruce Momjian) (9.4)(9.3)(9.2)(9.1)</li>
<li>pg_receivexlog と pg_recvlogical でローカライズメッセージ出力の失敗が修正されました。 (Ioseph Kim) (9.4)(9.3)(9.2)</li>
<li>ソケットの EOF を検知したときの libpq 入力バッファの早すぎる消去が修正されました。 (Tom Lane) (9.4)(9.3)</li>
<p>
この誤りにより libpq が、サーバからの予期せぬ切断を報告する手前の、バックエンドの最後のエラーメッセージを報告しないことが起こりまし</p>
<li>libpq のメモリ不足状況での振る舞いが改善されました。 (Michael Paquier, Amit Kapila, Heikki Linnakangas) (9.4)(9.3)(9.2)(9.1)</li>
<p>
これまで libpq が応答データを構成しているときにメモリ不足になると、サーバからのデータを待つ状態でハングアップしてしまいました。これが適切にエラーを出してクライアントに処理を戻すようになりました。
</p>
<li>ecpg が出力する typedef 文の引数順序が修正されました。 (Michael Meskes) (9.4)(9.3)(9.2)(9.1)</li>
<li>ecpg 実装の PGTYPESnumeric_from_double() で sprintf による変換で %f でなく %g を使うように修正されました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<p>
バッファオーバランの対策も加えられました。
</p>
<li>contrib/pgcrypto の crypt() 関数で確実に問い合わせキャンセルが可能となりました。 (Andreas Karlsson) (9.4)(9.3)(9.2)(9.1)</li>
<li>flex バージョン 2.5.x 以降に対応しました。 (Tom Lane, Michael Paquier) (9.4)(9.3)(9.2)(9.1)</li>
<p>
現在 flex 2.6.0 がリリースされていて、ビルドスクリプトにおけるバージョンチェックを調整する必要がありました。
</p>
<li>config/missing スクリプトをインストールするようになりました。 (Jim Nasby) (9.4)(9.3)(9.2)(9.1)</li>
<p>
bison などのビルドツールが無いマシン上で PGXSビルドを正常に行えるようになります。
</p>
<li>現在の libxml2 の振る舞いに適合する、別種のリグレッションテスト想定出力ファイルが追加されました。 (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<p>
libxml2 ライブラリは、セキュリティ障害 CVE-2015-7499 に対する修正で、ある種の場合にエラーコンテキストレポートが出力されなくなりました。これに対応した追加となります。
</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.1.19 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-1-19/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Thu, 08 Oct 2015 01:03:21 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.1]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=1860</guid>

					<description><![CDATA[このリリースは 9.1.18 からの修正リリース（2015年10月8日リリース）です。 9.1.x からのアップデートではダンプ、リストアは不要です。 また、9.1.16 より前のバージョンからアップデートを行う場合は  ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.1.18 からの修正リリース（2015年10月8日リリース）です。</p>
<p>9.1.x からのアップデートではダンプ、リストアは不要です。</p>
<p>また、9.1.16 より前のバージョンからアップデートを行う場合は <a href="/tech-blog/pgsql/9-1-16/">9.1.16 に関する技術情報</a> を参照してください。</p>
<p><span id="more-1860"></span></p>
<h3>PostgreSQL 9.1.18 から 9.1.19 への変更点</h3>
<p>9.4.5、9.3.10、9.2.14、9.1.19、9.0.23 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。 各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。<br />
<hr />
<ol>
<li>jsonのパースでスタックオーバーフローが防止されました。  (Oskari Saarenmaa) (9.4)(9.3)</li>
<p>
アプリケーションが PostgreSQL の json や jsonb の値を任意のユーザ入力から構成する場合、アプリケーションユーザは確実にサーバをクラッシュさせることができて、一時的なサービス不能をひき起こせます。
</p>
<li>pgcrypto拡張モジュールが crypt()関数の短すぎるソルトを検出して報告するように修正されました。  (Josh Kupershmidt) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
ある種の無効なソルト引数はサーバーをクラッシュさせるか、数バイトのサーバメモリを露出させました。露出した数バイトに秘密情報が在るように仕込む攻撃の可能性は排除しませんが、実現性は低いと見られます。(CVE-2015-5288)
</p>
<li>外側サブトランザクションに属するポータル（カーソル）が失敗した後のサブトランザクションのクリーンアップが修正されました。  (Tom Lane, Michael Paquier) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
外側サブトランザクションのカーソルで実行された関数が、内側サブトランザクションで作られたリレーション（一時テーブル等）を参照することで、アサート失敗かクラッシュを引き起こすことがありました。
</p>
<li>commit_delay が有効であるとき WAL挿入の際にデッドロックする可能性があり、修正されました。  (Heikki Linnakangas) (9.4)</li>
<p></p>
<li>UPDATE実行時に更新可能ビューから参照されている全てのリレーションが適切にロックされるようになりました。  (Dean Rasheed) (9.4)(9.3)</li>
<p></p>
<li>リレーションのリレーションキャッシュinitファイルへの格納について修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
直近のマイナーリリースでの不注意により、システムインデックスpg_trigger_tgrelid_tgname_index が initファイルで除外されていました。その後のセッションでこのことが検出され、initファイルが壊れていると見なされ、initファイルが無視されます。この結果、新規接続での所要時間が顕著に劣化しました。
</p>
<p>
本バグ修正では加えて、将来の類似の誤りが見つかるようにする防止策がいくつか導入されました。
</p>
<li>SPIクエリ結果に多数の行を投入するとき、O(N^2) の所要時間を要する振る舞いを回避するようになりました。  (Neil Conway) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
SPIクエリで結果行数が多いSQLを実行した場合に該当します。これまで必要メモリを追加するのに固定増分での追加確保をしていたため、処理回数が不要に多くなっていました。
</p>
<li>読まれない通知が多数ある場合の LISTEN 開始の所要時間が改善されました。  (Matt Newell) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
LISTEN/NOTIFY利用時において、一部の遅れたリスナーのために通知が大量に溜まっている状態で新たなリスナーを加えると、それらの溜まった通知を読み飛ばしていくのに処理コストを要していました。
</p>
<li>多数の外部キー制約を変更したセッションでの性能問題が修正されました。  (Jan Wieck, Tom Lane) (9.4)(9.3)</li>
<p>
これは主に数千テーブルを持つデータベースのダンプをリストアするときに見られます。
</p>
<li>SSL再ネゴシエーションがデフォルトでは無効となりました。  (Michael Paquier, Andres Freund) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
理論的には SSL再ネゴシエーションを使うことは良い考えですが、実際のところ OpenSSLライブラリに起因するもの、PostgreSQLにおけるライブラリの使い方に起因するもの、の双方で多数の障害が見られました。
</p>
<p>
再ネゴシエーションは PostgreSQL 9.5 以降では削除されます。9.4 以前のバージョン系列では、postgresql.conf の ssl_renegotiation_limit のデフォルト値が無効を意味する 0 に変更されます。
</p>
<li>*_freeze_max_age パラメータの下限値が引き下げられました。  (Andres Freund) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
主としてこれらパラメータに関するテストで時間がかからないようにするためですが、少ないディスクスペースにインストールする際にも価値があるかもしれません。
</p>
<p><pre>
autovacuum_freeze_max_age               100000  →      10000
autovacuum_multixact_freeze_max_age  100000000  →  100000000 (9.3以降)
</pre>
<p>上記のように変更されました。
</p>
<li>サーバクラッシュを避けるため wal_buffers の上限を 2GB までに限定しました。  (Josh Berkus) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
巨大な値を指定したとき整数オーバーフローによるクラッシュをひき起こしていました。なお、上限値 2GB は、実際には INT_MAX / XLOG_BLCKSZ の計算結果です。XLOG_BLCKSZ はビルド時の --with-wal-blocksize 指定値 × 1024 となります。
</p>
<li>postgresql.conf の読み込みについて修正されました。  (Tom Lane) (9.4)(9.3)</li>
<p>
サーバ開始時にしか指定できないパラメータが postgresql.conf の中に複数回あらわれた場合に苦情がログ出力されないようになりました。pg_ctl reload を行ったときに以下のようなメッセージが出ていました。
</p>
<pre>
LOG:  parameter "..." cannot be changed without restarting the server
</pre>
<p>
また、postgresql.conf のエラーを報告する際に include_dir 指定の後では行番号が誤って出力されており、修正されました。
</p>
<li>NUMERIC 値の掛け算における稀な内部オーバーフローが修正されました。  (Dean Rasheed) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
NUMERIC型の掛け算の結果に誤った値が返る可能性がありました。
</p>
<li>レコード型、範囲型、json型、jsonb型、tsquery型、ltxtquery型、および、query_int型に関連する稀なスタックオーバーフローを防ぐようになりました。  (Noah Misch) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
欠けていた max_stack_depth 設定値を超えていないかのチェック処理が、これらデータ型の各処理箇所に加えられました。
</p>
<li>日付時刻の入力において DOW と DOY の扱いが修正されました。  (Greg Stark) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
これらのトークンは日付時刻値では使えないはずですが、これまでは「invalid input syntax」でなく、意味の分からない内部エラーが出ていました。
</p>
<pre>
(以前の誤ったエラーメッセージ)
db1=# SELECT 'doy'::timestamptz;
ERROR:  unexpected dtype 33 while parsing timestamptz "doy"

(修正後の本来のエラーメッセージ)
db1=# SELECT 'doy'::timestamptz;
ERROR:  invalid input syntax for type timestamp with time zone: "doy"
</pre>
<li>正規表現照合中にクエリキャンセルのチェックをさらに追加しました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
正規表現処理がより迅速に中断要求に応じるようになります。
</p>
<li>正規表現、SIMILAR TO、LIKE の照合に再帰深度の保護が加えられました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
ある種の検索パターンと低いスタック深度制限により、スタックオーバーランによるクラッシュに至るおそれがありました。
</p>
<li>正規表現の実行で無限ループをひき起こす可能性があり、修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
一見ゼロ長文字列にマッチするけれども実際は後方参照によりマッチしないという検索パターンで無限ループに至る可能性がありました。
</p>
<p><pre>
SELECT 'a' ~ '$()|^1';  -- f
SELECT 'a' ~ '.. ()|1'; -- f
SELECT 'a' ~ '()*1';    -- t
SELECT 'a' ~ '()+1';    -- t
</pre>
<p>修正前バージョンでは上記のパターンマッチで無限ループに陥ります。
</p>
<li>正規表現の実行で、たとえマッチがゼロ長であったとしても、数量指定を含む括弧で捕捉されたマッチデータを正しく記録するようになりました。  (Tom Lane) (9.4)(9.3)(9.2)</li>
<p></p>
<li>正規表現のコンパイルでメモリ不足によるクラッシュの可能性があり、修正されました。  (Andreas Seltenreich) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
メモリ取得に失敗した場合の処理に不備があり、メモリ不足状態のサーバにおいて、NULLポインタ参照によるクラッシュを招く可能性がありました。
</p>
<li>低確率で生じる正規表現の実行時のメモリリークが修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p></p>
<li>トランザクションがアボートした際のロック解放処理における、稀なメモリ不足時の障害が修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
メモリ不足時にアサート失敗またはクラッシュをひき起こす可能性がありました。
</p>
<li>小さい work_mem設定でタプルストアを使用する場合に「unexpected out-of-memory situation during sort」エラーが生じる問題が修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
タプルストアとは SQL処理過程で一時的にデータを保持する内部的な仕組みです。
</p>
<li>qsort におけるごく稀なスタックオーバーランが修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
ここでの qsort は、ソート処理の内部実装の一つで、いわゆるクイックソートを実装しています。本障害によりクラッシュの可能性がありました。
</p>
<li>大きな work_mem 設定でのハッシュ結合にて、無効なメモリ割り当て要求サイズでエラーになることがあり、修正されました。  (Tomas Vondra, Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
「ERROR: invalid memory alloc request size」をひき起こすことがありました。
</p>
<li>プランナ関連の各種障害が修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
これら誤りは、間違った応答を返したり、アサート失敗したり、奇妙なプランナエラーを出したりするであろう不適切なクエリ実行プランを導きます。
</p>
<pre>
(本障害のプランナエラー例)
 ERROR: could not devise a query plan for the given query
 ERROR: could not find pathkey item to sort
 ERROR: plan should not reference subplan's variable
 ERROR: failed to assign all NestLoopParams to plan nodes
</pre>
<li>大きな継承セットにおける UPDATE/DELETE のプランナ性能が改善しました。  (Tom Lane, Dean Rasheed) (9.4)(9.3)(9.2)</li>
<p>
これまで、継承テーブル数に対して O(N^2) 処理を要する箇所がありました。
</p>
<li>スタンバイ昇格トリガファイルがマスタプロセス(postmaster)起動時に確実に削除されるようになりました。  (Michael Paquier, Fujii Masao) (9.4)(9.3)(9.2)(9.1)</li>
<p>
新たなスタンバイサーバを作るためのデータベースバックアップにトリガファイルが含まれていた場合に、望まない昇格が起きるのを防ぎます。
</p>
<li>マスタプロセス(postmaster) がシャットダウンするとき、pidファイルが削除される前に、確実にソケット毎のロックファイルが削除され、リッスンソケットが閉じられるようになりました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
外部スクリプトが pg_ctl stop のすぐ後に PostgreSQL を起動した場合に、競合して起動に失敗するのを防ぎます。
</p>
<li>たとえ immediate シャットダウンであっても、全ての子プロセスがいなくなるまではマスタプロセス(postmaster) は終了しないようになりました。  (Tom Lane) (9.4)</li>
<p></p>
<li>クラッシュリカバリ中にクラッシュしたスタートアッププロセスの扱いが修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
クラッシュリカバリ処理はスタートアッププロセスの中で行われます。これまで、データベース一貫性が無い状態でスタートアッププロセスがクラッシュした場合、新たにスタートアッププロセス起動を試みていましたが、これは通常は再度クラッシュすることになり、無限ループに至ります。
</p>
<p>
スタートアップ中のクラッシュの後は自動再起動せず、終了するようになります。
</p>
<li>マルチトランザクション周回に対する緊急自動VACUUM がより頑健になりました。  (Andres Freund) (9.4)(9.3)</li>
<p>
これまでは必要でも必ずしも自動VACUUM が駆動されないというケースがありました。
</p>
<li>シグナルを送ろうとしたら autovacuum worker プロセスが既にいなくなっていた場合に警告を出さないようになりました。また、自動VACUUM 関連シグナルのログ出力が減りました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
相手プロセスが居ない場合に「WARNING: could not send signal to process ...」が出ていました。 また、ロック競合した自動VACUUM をキャンセルする際に発生する「LOG: sending cancel to blocking autovacuum PID ...」メッセージが、DEBUG1 レベルに変更されました。
</p>
<li>サーバ時計が大きく戻ったときに、autovacuum launcherプロセスが過度に長く休止するのが防止されました。  (&Aacute;lvaro Herrera) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p></p>
<li>GIN インデックスの挿入保留リストのクリーンアップがキャンセル要求により確実に割り込み可能になりました。  (Jeff Janes) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
このクリーンアップ処理は通常 GIN インデックスを持つカラムの INSERT、UPDATEで発生します。
</p>
<li>GIN インデックスで全てゼロのページが再利用可能になりました。  (Heikki Linnakangas) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
このようなページはクラッシュ後にできることがあります。これまで全てゼロのページは再利用されず、無駄に領域を占めていました。
</p>
<li>SP-GiST インデックスにおける全てゼロのページの扱いが修正されました。  (Heikki Linnakangas) (9.4)(9.3)(9.2)</li>
<p>
VACUUM でこのようなページを再利用しようとしますが、WAL出力を伴うクラッシュセーフな方法で処理していませんした。
</p>
<li>サブトランザクション、マルチトランザクションの切捨て処理が修正されました。  (Thomas Munro) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
「LOG: could not truncate directory "...": apparent wraparound」メッセージが不必要に出力されることがありました。なお、修正前においてもログメッセージを出す以外は無害です。
</p>
<li>PL/pgSQL エラーのコンテキストメッセージで CONTINUE と MOVE のステートメントタイプを誤って報告していたのが修正されました。  (Pavel Stehule, Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
CONTINUE であるべきところが EXIT と、MOVE であるべきところが FETCH と報告されていました。
</p>
<pre>
ERROR:  ...(何らかメッセージ)...
CONTEXT:  PL/pgSQL function myfunc() line 123 at FETCH (← この部分)
</pre>
<li>PL/Perl が非ASCII のエラーメッセージ文面を正しく扱うように修正されました。  (Alex Hunsaker) (9.4)(9.3)(9.2)(9.1)</li>
<p></p>
<li>PL/Python でレコード結果の文字列表現を返すときにクラッシュする障害が修正されました  (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<p></p>
<li>PL/Tcl で malloc() 呼び出し失敗のチェックを怠っているいくつかの箇所が修正されました。  (Michael Paquier, &Aacute;lvaro Herrera) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p></p>
<li>contrib/isn で 979 から始まる ISBN-13 番号の出力が修正されました。  (Fabien Coelho) (9.4)(9.3)(9.2)(9.1)</li>
<p>
(9790 ではなく) 979 から始まる EAN は ISBN と見做せますが、10桁形式ではなく、新しい13桁の形式で出力される必要がありました。
</p>
<pre>
(修正前)
db1=# SELECT ('9791234567896'::EAN13)::ISBN;
    isbn
-------------
 123456789-X
(1 row)

(修正後)
db1=# SELECT ('9791234567896'::EAN13)::ISBN;
      isbn
-----------------
 979-123456789-6
(1 row)
</pre>
<li>contrib/pg_stat_statements の問い合わせ文字列のガベージコレクションが改良されました。  (Peter Geoghegan) (9.4)</li>
<p>
問い合わせ文字列が格納される外部ファイルは巨大なサイズに膨らむことがありえました。これまではファイルサイズが一度 1GB を超えると読み込みできませんでした。このサイズ上限が引き上げられ、また、読み込み失敗したときにファイルをリセットするようになりました。
</p>
<li>contrib/postgres_fdw で照合関連の判定処理が改善されました。  (Tom Lane) (9.4)(9.3)</li>
<p>
目に見える変化としては、varcharカラムを含む比較が以前より多くのケースでリモートサーバに送られて実行されるようになります。
</p>
<li>libpq でメモリ不足状態のときの処理が改善されました。  (Michael Paquier, Heikki Linnakangas) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
これまでそのように報告していなかった箇所でメモリ割り当てに失敗したときに「out of memory」とエラーメッセージを出すようになりました。
</p>
<li>ecpg でメモリリークと、メモリ不足ケースのチェックが欠けている箇所があり、修正されました。  (Michael Paquier) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p></p>
<li>psql でロケールを意識した数の出力形式について修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
「pset numericlocale on」を指定した場合に一部のケースで誤動作をしていました。
</p>
<pre>
(修正前の障害動作例)
=# pset numericlocale on
Locale-adjusted numeric output is on.

=# SELECT 1000000::real;
 float4
--------
 1e,+06
(1 row)

=# SELECT 10000::money;
    money
--------------
 $,10,,000.00
(1 row)
</pre>
<li>psql で現在の接続が無いときに c コマンドでクラッシュするのが防止されました。  (Noah Misch) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<pre>
(クラッシュ例 - サーバ側からの強制切断後に c 実行)

server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

!&gt; c db1 dbuser1 localhost 5432
セグメンテーション違反です (コアダンプ)
</pre>
<li>pg_dump が継承されたテーブルの NOT VALID の CHECK制約を正しく扱うようになりました。  (Tom Lane) (9.4)(9.3)(9.2)</li>
<p>
リストアするとエラーが生じる誤ったダンプを出力することがありました。
</p>
<li>pg_dump のディレクトリ出力フォーマットでデフォルトの zlib 圧縮レベル指定について修正されました。  (Andrew Dunstan) (9.4)(9.3)(9.2)(9.1)</li>
<p>
これまでマニュアルに記載された「中間レベル」ではなく、速さ優先の圧縮レベルがデフォルト動作になっていました。
</p>
<li>tarフォーマット出力の pg_dump で作られる一時ファイルのファイルモードが誰でも読み取り可能とならないようになりました。  (Michael Paquier) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p></p>
<li>pg_dump と pg_upgrade が postgres や template1 データベースがデフォルトテーブルスペース以外にある場合に対応するように修正されました。  (Marti Raudsepp, Bruce Momjian) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p></p>
<li>pg_dump が旧バージョン PostgreSQL からのダンプでオブジェクト権限を正常に扱うように修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p></p>
<p>
PostgreSQL 9.2 より前のサーバからデータ型をダンプするとき(※1)、あるいは、7.3 より前のサーバから関数や手続き言語をダンプするとき、pg_dump は、所有者の権限を剥奪して代わりに PUBLIC に全ての権限を与えるようなGRANT/REVOKE コマンドを出力していました。
</p>
<p>
該当するのは USAGE と EXECUTE 権限だけですのでセキュリティ問題ではありません。この場合はデフォルト権限状態のままにするように修正しました。
</p>
<pre>
※1 これは 9.2.x、9.3.x、9.4.x の場合のみ
</pre>
<li>pg_dump がシェル型をダンプするように修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
シェル型は未だ定義が無いプレースホルダとして名前だけ与えられたデータ型です。
</p>
<li>pg_dump ほかいくつかのクライアントプログラムで影響度の低いメモリリーク等が修正されました。  (Michael Paquier) (9.4)(9.3)(9.2)(9.1)</li>
<p></p>
<li>クエリや pgbench自身が固まった場合の pgbench の進捗報告の振る舞いが修正されました。  (Fabien Coelho) (9.4)</li>
<p></p>
<li>Alpha アーキテクチャむけのスピンロックのアセンブリコードが修正されました。  (Tom Lane) (9.4)</li>
<p></p>
<li>PPC アーキテクチャむけのスピンロックのアセンブリコードが AIX のネイティブアセンブラに対応するように修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p></p>
<li>AIX でこれまで単に使えるものと想定していた -qlonglong コンパイラオプションをテストするようになりました。  (Noah Misch) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p></p>
<li>AIX で実行時にシンボル解決できるようにする -Wl,-brtllib リンクオプションを使うようになりました。  (Noah Misch) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p></p>
<li>コンパイラバグのため 32bit xlc でインライン関数展開を使わないようになりました。  (Noah Misch) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p></p>
<li>必要に応じて sched_yield() むけに librt を使うようになりました。いくつかの Solaris バージョンで該当します。  (Oskari Saarenmaa) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p></p>
<li>UHC エンコーディングを Windows コードページ 949 として変換するようになりました。  (Noah Misch) (9.4)</li>
<p>
これにより、データベースに紐づかないプロセス(postmaster等)から非ASCII のログメッセージが出るのを修正しました。
</p>
<li>Windows でトランザクション外での UTF16 への文字エンコーディング変換(ログメッセージ用など) で失敗するのが防止されました。  (Noah Misch) (9.4)</li>
<p></p>
<li>setlocale() の返し値をコピーしないことによる、マスタープロセス(postmaster) の起動失敗が修正されました。  (Noah Misch) (9.4)</li>
<p>
本現象は ANSI コードページを CP936 (中国語 簡体字/PRC) に設定した Windows で報告され、他のマルチバイトコードページでも発生するとみられます。
</p>
<li>Windows の install.bat スクリプトについて、空白文字を含む対象ディレクトリ名の処理が修正されました。  (Heikki Linnakangas) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p></p>
<li>PostgreSQLバージョン番号の数値表現(90405 など) が、拡張モジュールのMakefile で VERSION_NUM 変数として利用可能になりました。  (Michael Paquier) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p></p>
<li>タイムゾーンデータファイルが tzdata release 2015g に更新されました。   (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
ケイマン島、フィジー、モルドバ、モロッコ、ノーフォーク島、北朝鮮、トルコ、ウルグアイの夏時間方式が変更されました。新しいタイムゾーン名としてカナダ・ノーザンロッキーの America/Fort_Nelson が加わりました。
</p>
<li>9.3 以降で加わったリソース所有者ごとのロックキャッシュが後方適用されました。  (Jeff Janes) (9.2)(9.1)</li>
<p>
pg_dump で多数のテーブルをダンプするときの性能を改善します。
</p>
<li>contrib/sepgsql の SELECT INTO 命令の扱いが修正されました。  (Kohei KaiGai) (9.2)</li>
<p></p>
<li>プランナにおけるあいまいパスコストの同点決勝ルールが後方適用されました。  (Tom Lane) (9.1)(9.0)</li>
<p>
本変更により、同コストプランの選択においてプラットフォーム固有の振る舞いを避けることができます。
</p>
</ol>
</p>
<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.1.18 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-1-18/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Fri, 12 Jun 2015 01:01:45 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.1]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=2049</guid>

					<description><![CDATA[このリリースは 9.1.17 からの修正リリース（2015年6月12日リリース）です。 9.1.x からのアップデートではダンプ、リストアは不要です。 また、9.1.16 より前のバージョンからアップデートを行う場合は  ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.1.17 からの修正リリース（2015年6月12日リリース）です。</p>
<p>9.1.x からのアップデートではダンプ、リストアは不要です。</p>
<p>また、9.1.16 より前のバージョンからアップデートを行う場合は <a href="/tech-blog/pgsql/9-1-16/">9.1.16 に関する技術情報</a> を参照してください。</p>
<p><span id="more-2049"></span></p>
<h3>PostgreSQL 9.1.17 から 9.1.18 への変更点</h3>
<p>9.4.4、9.3.9、9.2.13、9.1.18、9.0.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。 各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。<br />
<hr />
<ol>
<li>一貫性のないデータベース状態からのリカバリに失敗する可能性があり、修正されました  (Robert Haas) (9.4) (9.3)</li>
<p>
最近のPostgreSQLリリースでマルチトランザクション周回を防ぐ仕組みが導入されましたが、実装の一部において発生する可能性をつぶせていませんでした。一貫性の無い状態データベースをクラッシュリカバリする際に漏れることがあります。この結果、クラッシュ後の再起動やスタンバイサーバの最初の起動に失敗する可能性がありました。バージョン 9.3.0 から 9.3.4 の pg_upgrade を使ったインストールでも、同様の障害をひき起こします。
</p>
<p>
pg_upgrade の誤りは、pg_control の oldestMultiXid をもっと大きい値にすべき場合でも 1 に設定していたことです。本リリースの修正後は、このような状況では緊急自動VACUUM となり、oldestMultiXid の正しい値が定まるまで実行されます。アップグレードを開始する前にあらかじめ VACUUM を実行しておくことで、このような動作を避けることができます。
</p>
<li>稀におきるリレーションキャッシュ初期化ファイル(pg_internal.init)の無効化失敗が修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
同時実行のタイミングによっては、システムカタログの VACUUM FULL が、新たなセッションでキャッシュローディングを避けるのに使われる初期化ファイルの更新に、失敗することがありえました。結果として、後のセッションがそのシステムカタログにまったくアクセスできなくなってしまいます。
</p>
<p>
障害発生時には「cache lookup failed」や「could not open file」といったエラーが発生すると考えられ、解消には pg_internal.init ファイルを手動で削除するほかありません。
</p>
<li>新たなセッション開始と CREATE/DROP DATABASE のデッドロックを回避するようになりました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
DROP DATABASE で削除するデータベースや、CREATE DATABASE でテンプレートに使うデータベースに新たなセッションを開始すると、これらコマンドは 5秒待って（競合するセッションがその前に終了していたとしても）エラーになっていました。
</p>
<li>内側のインデックススキャンを伴う semi-join、anti-join についてプランナのコスト見積もりが改善されました。  (Tom Lane, Tomas Vondra) (9.4)(9.3)</li>
<p>
全ての結合節がインデックススキャン条件として使われている場合、たとえ内側スキャンが見かけ上多数の行を読み出すとしても、エグゼキュータは一行を取得した後に止まるので、低コストなプランとなります。
</p>
<p>
プランナはこの効果について部分的にしか考慮しておらず、結果としてコストを過大評価して、劣った別のプランが選択される原因となっていました。
</p>
</ol>
</p>
<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.1.17 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-1-17/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Thu, 04 Jun 2015 01:01:49 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.1]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=2104</guid>

					<description><![CDATA[このリリースは 9.1.16 からの修正リリース(2015年6月4日リリース)です。 9.1.x からのアップデートではダンプ、リストアは不要です。 また、9.1.16 より前のバージョンからアップデートを行う場合は 9 ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.1.16 からの修正リリース(2015年6月4日リリース)です。<br />
9.1.x からのアップデートではダンプ、リストアは不要です。</p>
<p>また、9.1.16 より前のバージョンからアップデートを行う場合は <a href="/tech-blog/pgsql/9-1-16/">9.1.16 に関する技術情報</a>を参照してください。</p>
<p><span id="more-2104"></span></p>
<h3 class="background">PostgreSQL 9.1.16 から 9.1.17 への変更点</h3>
<p>9.4.3、9.3.8、9.2.12、9.1.17、9.0.21 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<hr />
<ol class="technology">
<li>クラッシュ後の再起動でデータディレクトリに fsync をかけるときの失敗を回避するようになりました。  (Abhijit Menon-Sen, Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
一つ前のマイナーリリースで、クラッシュ後にデータディレクトリ内の全てに fsync をかける修正が加わりましたが、これは全ての状況に対応できていませんでした。これにより、無害な問題であってもサーバの起動が妨げられてしまいます。
</p>
<p>
具体的には、書き込み不能なファイルが含まれていた場合に一部プラットフォームでは再起動できなくなってしまいます。とはいえ、サーバで SSL証明書ファイルを書き込み不能にするのは一般的です。
</p>
<p>
本修正は改定され、全体的にパーミッションによる失敗は無視されるようになりました。また、他の失敗もログ出力されますが、処理の継続は止めないようになりました。
</p>
<p>
PostgreSQL 9.4系については、重要度は低いですが同様に振る舞うべきであるため、initdb の --sync-only オプションも同じ規則で動作するようになりました。
</p>
<li>pg_get_functiondef() 関数が、設定されているならLEAKPROOF属性を出力するように修正されました。  (Jeevan Chalke) (9.4)(9.3)(9.2)</li>
<p>
pg_get_functiondef() 関数は psql の ef コマンドで使われます。
</p>
<li>内部実装用の pushJsonbValue()関数が jbvBinaryオプジェクトを展開するように修正されました。  (Andrew Dunstan) (9.4)</li>
<p>
jbvBinary とは JSONBデータ型の内部格納データ区分の一つです。本変更による PostgreSQL本体の振る舞い変更はありませんが、拡張モジュールからの呼び出しにおける例外的な問題ケースを回避します。
</p>
<li>configure の OpenBSD におけるスレッド対応したlibpythonへのリンクを禁止する検査が除去されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
最近のテストでは問題なく動作しており、禁止する必要がないと判断されました。
</p>
<li>libpq で TLSプロトコルバージョン v1 以上が利用可能になりました。  (Noah Misch) (9.3)(9.2)(9.1)(9.0)</li>
<p>
これまで libpq は SSLプロトコルとして TLS v1 のみが使えました。現在ではより新しいバージョンが一般的です。PostgreSQLサーバでは既に対応しており、サーバ側の変更はありません。
</p>
</ol>

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

]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>PostgreSQL 9.1.16 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-1-16/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Fri, 22 May 2015 01:01:55 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.1]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=2129</guid>

					<description><![CDATA[このリリースは 9.1.15 からの修正リリース(2015年5月22日リリース)です。 9.1.x からのアップデートではダンプ、リストアは不要です。 また、9.1.15 より前のバージョンからアップデートを行う場合は  ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.1.15 からの修正リリース(2015年5月22日リリース)です。<br />
9.1.x からのアップデートではダンプ、リストアは不要です。</p>
<p>また、9.1.15 より前のバージョンからアップデートを行う場合は <a href="/tech-blog/pgsql/9-1-15/">9.1.15 に関する技術情報</a>を参照してください。</p>
<p>特に contrib/citext 拡張モジュールの regexp_matches() 関数について、 将来の仕様変更を伴う修正が適用されていますので、当該項目を確認ください。</p>
<p><span id="more-2129"></span></p>
<h3 class="background">PostgreSQL 9.1.15 から 9.1.16 への変更点</h3>
<p>9.4.2、9.3.7、9.2.11、9.1.16、9.0.20 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<hr />
<ol class="technology">
<li>認証タイムアウトになる直前にクライアントが切断した時に、クラッシュする可能性が回避されました。  (Benkocs Norbert Attila) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
タイムアウトの割り込みが、セッション切断処理中に発生すると、SSL 関連情報が二重解放されクラッシュし、その結果、他のセッションへの DoS となります。実験では認証されていないリモート攻撃者が、一貫してバグを引き起こすことが可能なため、セキュリティ上の問題として扱っています。(CVE-2015-3165)
</p>
<li>システムコール失敗の判定が改善されました。  (Noah Misch) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
snprintf() などの代替実装では、下位のシステムライブラリ呼び出しでのエラーチェックに間違いがありました。主な問題は、メモリ不足の状況での対応不足にあります。最悪の場合、実装コードでは、バッファが上書きされていないのに、上書きされたとみなすことにより、情報が漏洩する可能性があります。
</p>
<p>
他の *printf() ファミリ関数呼び出しにも、悪い時にメモリ不足を起こすと、情報漏洩する脆弱性が残っている可能性があります。開発コミュニティは、大きなリスクではないと判断していますが引続き解析を続けるとのことです。(CVE-2015-3166)
</p>
<li>contrib/pgcrypto の復号失敗時のメッセージを、間違ったキーか不正なデータかによらず統一しました。  (Noah Misch) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
以前は、間違ったキーによる復号では、異なったエラーメッセージが報告されていました。その様なエラーメッセージの違いは、他のシステムを使ってキーを見つけようとする攻撃者への助けになることが知られています。pgcrypto のこの振る舞いが攻撃に利用できるかは不明ですが、単一のメッセージを使う方が、リスクを避けるのに良いと考えられます。(CVE-2015-3167)
</p>
<li>マルチトランザクションID 処理の周回対策が行われました。  (&Aacute;lvaro Herrera, Robert Haas, Thomas Munro) (9.4)(9.3)</li>
<p>
特定の利用パターンだと、既存の対策が不十分なため pg_multixact/members ファイルが早くに削除されてしまい、結果としてデータを損失します。<br />
サーバ側修正として、古いマルチトランザクションメンバ ID を上書きしそうな場合、トランザクションを「multixact "members" limit exceeded」エラーで失敗させるようになります。<br />
autovacuum の改良として、トランザクション ID の周回と同様、マルチトランザクション ID の周回防止の活動を行なうようになります。
</p>
<li>contrib/citext モジュールの regexp_matches() 関数の間違っていた宣言が修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)</li>
<p>
この関数は text 型に対する定義と同様に citext型に対しても setof text[] を返すべきですが、text[] を返すように宣言されていました。このため、マッチしない場合に 0 行が返るのでなく NULL が返る、'g' フラグを指定しても実質的には無視される、という振る舞いになっていました。
</p>
<pre>
db1=# SELECT id, v AS v_is_citext FROM t5;
 id |  v_is_citext
----+----------------
  1 | pgsql is PGSQL
  2 | pgSQL
(2 rows)

db1=# SELECT id, regexp_matches(v, 'xxxxx'::citext) FROM t5;
【本来期待された振る舞い】
 id | regexp_matches
----+----------------
(0 rows)

【これまでの振る舞い】
 id | regexp_matches
----+----------------
  1 |
  2 |
(2 rows)

db1=# SELECT id, regexp_matches(v, 'pgsql'::citext, 'g') FROM t5;
【本来期待された振る舞い】
 id | regexp_matches
----+----------------
  1 | {pgsql}
  1 | {PGSQL}
  2 | {pgSQL}
(3 rows)

db1=# SELECT id, regexp_matches(v, 'pgsql'::citext, 'g') FROM t5;
【これまでの振る舞い】
 id | regexp_matches
----+----------------
  1 | {pgsql}
  2 | {pgSQL}
(2 rows)
</pre>
<p>
これまでの振る舞いに依存するアプリケーションが存在する可能性があるため、デフォルトの宣言は PostgreSQL 9.4 以前では変更されません。9.4 以前では、従来の宣言は拡張モジュールのバージョン 1.0 として提供され、正しい宣言は拡張モジュールのバージョン 1.1 として提供されます。以下のようにしてバージョン 1.1 に上げることができます。
</p>
<pre>
db1=# ALTER EXTENSION citext UPDATE TO '1.1';
db1=# dx
                           List of installed extensions
  Name   | Version |   Schema   |                   Description
---------+---------+------------+--------------------------------------------------
 citext  | 1.1     | public     | data type for case-insensitive character strings
 plpgsql | 1.0     | pg_catalog | PL/pgSQL procedural language
(2 rows)
</pre>
<li>json 型への変換で、無限大の日付や時刻はエラーにせず 'infinity' にするようになりました。  (Andrew Dunstan) (9.4)</li>
<li>json/jsonb の populate_record() と to_record() 関数が、空の入力を正しく扱うようになりました。  (Andrew Dunstan) (9.4)</li>
<li>HOT 更新後の遅延された排他制約の誤った検査が修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
本来は無視されるべき排他制約違反が報告されることがありました。
</p>
<p>
遅延された排他制約に違反する可能性のある新しい行が同トランザクションで後に HOT更新された場合、後に削除される行が新たな行と当初に衝突していた場合でも、排他制約違反が最後のチェックで報告されることがありえました。
</p>
<li>ALTER TABLE ... ALTER CONSTRAINT で外部キー制約の遅延可能状態を変更するときの振る舞いが修正されました。  (Tom Lane) (9.4)</li>
<p>
これまで、後に続く同セッションでの操作、または同時実行の別セッションにて、変更を即座に尊重しないことがありました。
</p>
<li>スタースキーマ式クエリのプラン作成が修正されました。  (Tom Lane) (9.4)(9.3)(9.2)</li>
<p>
大きなテーブルの効果的なスキャンでは、インデックスパラメータが複数の結合テーブルから提供されることがしばしば必要となります。プランナはこのような計画を発見できないといけませんが、これまで、あまりに制限的なヒューリスティック検索がこれを妨げていました。
</p>
<p>
t10_fact が行数の非常に多いテーブル、t10_dim_a と t10_dim_b が行数の少ないテーブルであるとしたときの、以下のようなクエリであって、a.c1 = 1 と b.c1 = 2 の二つの条件で選択行を大幅に限定できるという場合が該当します。
</p>
<pre>
SELECT * FROM t10_fact f, t10_dim_a a, t10_dim_b b
  WHERE f.aid = a.id AND f.bid = b.id AND a.c1 = 1 AND b.c1 = 2;
</pre>
<li>他の外部結合に対する anti-join (NOT EXISTS 結合) の不適切な配置換えを防止するようになりました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
プランナにおける本障害により「could not find RelOptInfo for given relids」エラーがあらわれます。しかし時には、誤ったクエリプランが一貫性チェックをパスして、エラーを出すことなく誤ったクエリ実行結果を返す可能性もあります。
</p>
<li>外部結合プランノードでの部分式の誤ったマッチングが修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
これまでは、外形上同一の STRICT でない(すなわち NULL入力が認められる) 部分式が外部結合の上位と下位とで使われているとき、プランナが結合の下位で計算した値を再利用しようとすることがありました。<br />エグゼキュータは外部行にマッチしない場合は値を NULL にするため、これは誤った動作でした。
</p>
<p>
以下に障害動作例を示します。
</p>
<pre>
db1=# CREATE TABLE t12 (c1 int, c2 int);
db1=# INSERT INTO t12 VALUES (1,NULL),(NULL,2);
db1=# SELECT a.c1 AS a_c1, b.c2 AS b_c2 FROM t12 a
        LEFT JOIN t12 b ON a.c2 = coalesce(b.c1, 1)
        WHERE coalesce(b.c1, 1) &gt; 0;
【9.4.2 での結果】
 a_c1 | b_c2
------+------
      |
    1 |
(2 rows)

【9.4.1 での誤った結果】
 a_c1 | b_c2
------+------
(0 rows)
</pre>
<li>結合順序のヒューリスティック手法が失敗した場合に対応できるように GEQO プランナが修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
本障害により、LATERALを含むクエリでエラー「failed to join all relations together」が出ます。また、その他の場合でも発生する可能性があります。
</p>
<li>UPDATE、DELETE 対象がセキュリティバリアビューであるとき、適切に行ロックが確実に生じるように修正されました。  (Stephen Frost) (9.4)</li>
<p>
これまで行ロック処理が欠落してしまうことがありました。
</p>
<li>PostgreSQL 起動時にレプリケーションスロットのデータを同期するとき、ファイルを read/write で開くようになりました。  (Andres Freund) (9.4)</li>
<p>
一部のプラットフォームでは、これまでのコードでは「could not fsync file "pg_replslot/...": Bad file descriptor.」というエラーをひき起こしていました。
</p>
<li>max_prepared_transactions が小さすぎる場合に PostgreSQL 起動時のデッドロックの可能性があり、修正されました。  (Heikki Linnakangas) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
未コミットのプリペアドトランザクションよりも小さい max_prepared_transactions を指定して、再起動すると、PostgreSQL のマスタプロセスが残ったまま起動に失敗する例が報告されました。
</p>
<li>タイムラインが切り替わった後に使えない事前割り当てされた WAL ファイルをアーカイブしないようになりました。  (Heikki Linnakangas) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<li>クラッシュ後に再帰的にデータディレクトリの fsync() を行うようになりました。  (Abhijit Menon-Sen, Robert Haas) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
これにより、別のシステムレベルのクラッシュがすぐ後に起きた場合でも、一貫性を確実にします。
</p>
<li>autovacuum ランチャープロセスが、SIGTERM シグナルを受け取った後にエラーが起きた場合に、シャットダウンに失敗していたものが修正されました。  (&Aacute;lvaro Herrera) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<li>セッション開始初期のシステムカタログに対する無効化メッセージの扱いが修正されました。  (Tom Lane) (9.4)</li>
<p>
本障害は システムカタログに対する VACUUM FULL を同時に開始するセッションで失敗をひき起こしていました。
</p>
<li>BackendIdGetTransactionIds() で、ちょうど終了したバックエンドプロセスの状態取得を試みたときのクラッシュが修正されました。  (Tom Lane) (9.4)</li>
<li>LockBufferForCleanup() での予期せぬシグナルに対処するようになりました。  (Andres Freund) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
この誤りは「multiple backends attempting to wait for pincount 1」という偽性の（本来はエラーではない）エラーをひき起こしていました。
</p>
<p>
なお、ピンとはバッファページに対するアクセスを排他制御する内部的なロック機構の一つです。
</p>
<li>行全体を参照するチェック制約の付いたテーブルに対する COPY IN 実行時のクラッシュが修正されました。  (Tom Lane) (9.4)(9.3)(9.2)</li>
<p>
クラッシュすることが知られているのは 9.4 以上だけですが、同様のコードが 9.3、9.2 にあるため、合わせて修正されています。
</p>
<pre>
(障害再現例)
db1=# CREATE TABLE t23 (id int primary key , c1 int, c2 int);
db1=# CREATE FUNCTION check_con_func(t23) RETURNS boolean
  LANGUAGE plpgsql IMMUTABLE AS $$ BEGIN RETURN ($1.c1 &gt; 0); END $$;
db1=# ALTER TABLE t23 ADD CHECK (check_con_func(t23.*));
db1=# COPY check_con_tbl FROM STDIN;
&gt;&gt; 0      0       0
&gt;&gt; 1      1       1
&gt;&gt; .
server closed the connection unexpectedly
</pre>
<li>read-only であるトランザクションのコミットでは、そのユーザに限り、WAL フラッシュや同期レプリケーションを待たないようになりました。  (Andres Freund) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
これまでは（参照処理でも）HOT ページ掃除のために WALを書くトランザクションにおいて遅延がありえ、全スタンバイがダウンしている場合には、固まってしまいました。また、同期レプリケーションのときのキャッチアップ割り込み処理でも固まることがありました。本修正はこれらの問題を解消します。
</p>
<li>recovery_min_apply_delay に短い時間が設定されているときのビジーウェイトを回避するようになりました。  (Andres Freund) (9.4)</li>
<p>
ミリ秒以下の遅延設定は無視されるようになります。
</p>
<li>一時テーブル上のハッシュインデックスを操作するときに生じるクラッシュが修正されました。  (Heikki Linnakangas) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<li>他プロセスが同時にインデックスを変更している場合、ハッシュインデックスのバケツ分割に失敗する可能性があり、修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<li>GIN インデックスの VACUUM におけるメモリリークが修正されました。  (Heikki Linnakangas) (9.4)</li>
<li>インデックス式の ANALYZE 中に割り込みをチェックするようになりました。  (Jeff Janes) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
ANALYZE ではインデックスの式を多数実行します。この式の中に遅い関数があった場合、ANALYZE を処理ループが終わる前にキャンセルできることが望まれます。
</p>
<li>行ロック後に READ COMMITTED 再チェックが生じたときに、外部テーブルのテーブルOID が確実に正しく報告されるようになりました。  (Etsuro Fujita) (9.4)(9.3)(9.2)(9.1)</li>
<p>
これまで外部テーブルのテーブルOID には無効な値が設定されていましたが、上記ケースでは意味のある値が必要とされ、適切に動作しませんでした。
</p>
<li>外部サーバユーザマッピングのオブジェクト説明文字列にターゲットサーバ名が追加されました。  (&Aacute;lvaro Herrera) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
出力メッセージにあらわれる「user mapping for {ユーザ名}」が、「user mapping for {ユーザ名} on server {サーバ名}」となります。
</p>
<li>符号化方式変換オブジェクトのオブジェクト識別文字列にスキーマ名が含まれるようになりました。  (&Aacute;lvaro Herrera) (9.4)(9.3)</li>
<li>Kerberos/GSSAPI/SSPI 認証でオプション設定に include_realm=1 を推奨するようになりました。  (Stephen Frost) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
ドキュメントのみ修正されています。PostgreSQL 9.5 からデフォルトで include_realm=1 となる予定です。
</p>
<li>IPv4 の pg_hba.conf 項目を IPv4-in-IPv6 アドレスと照合する機能が除去されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
本機能は 2003年に追加されましたが、9.0 で適切に動作していませんでした。この壊れたコードが一部のシステムでクラッシュをひき起こすことが報告されました。
</p>
<li>実際には起動しなかったバックグラウンドワーカが終了したときの状態報告が修正されました。  (Robert Haas) (9.4)</li>
<p>
拡張モジュール作成用の API の動作変更となります。GetBackgroundWorkerPid() の応答が変更されました。
</p>
<li>データベースクラッシュ後、BGW_NEVER_RESTART 属性が指定されているバックグラウンドワーカは再起動しないようになりました。  (Amit Khandekar) (9.4)</li>
<p>
PostgreSQLソースコードに含まれる機能や拡張モジュールの中で、contrib/worker_spi と contrib/test_shm_mq 以外で本変更の影響を受けるものはありません。
</p>
<li>レプリケーションコマンド IDENTIFY_SYSTEM の応答で WAL 挿入でなく、WALフラッシュの位置を報告するようになりました。  (Heikki Linnakangas) (9.4)(9.3)(9.2)(9.1)</li>
<p>
これにより pg_receivexlog が、取得しようとしたデータがまだ WALファイルに書き込まれていないことで、起動失敗する可能性を回避します。
</p>
<li>Windows でサービス停止するときに、サービスが早くに強制終了されてしまうのを防ぐために、サービスコントロールマネージャに周期的に状態を送るようになりました。  (Krystian Bigaj) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
また、pg_ctl が確実にシャットダウンを待つようになりました。
</p>
<li>libpq でノンブロッキングモードを使うときのネットワークデッドロックの危険性が軽減されました。  (Heikki Linnakangas) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
大きいデータを送るとき、サーバが出力をブロックするほどの応答データを送ってくることに備えて、入力バッファが時々に捌けることが重要となります。典型的なシナリオは、サーバが COPY FROM STDIN の実行中に連続して NOTICE メッセージを送ってくる場合です。このとき、通常のブロッキングモードなら問題ありませんが、ノンブロッキングモードの場合、デッドロックの危険性があります。
</p>
<p>
libpq は日和見的に可能であれば入力を排出するように修正されました。完全にネットワークデッドロックを防ぐためには、アプリケーションの協力が必要です。アプリケーションは write-ready 状態だけでなく、read-ready に気を付けなければならず、read-ready 状態で確実に PQconsumeInput() を呼ばなければいけません。
</p>
<li>libpq でURI接続文字列の空値の解析の誤りが修正されました。  (Thomas Fanghaenel) (9.4)(9.3)(9.2)</li>
<p>
1文字分の配列オーバーラン参照が生じていました。クライアント側のメモリ読み取りであり、セキュリティ上の危険性はありません。
</p>
<li>ecpg で配列の扱いが修正されました。  (Michael Meskes) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
一次元配列について C 言語の配列へのマッピングがサポートされました。
</p>
<li>psql が connect の最初の引数として URI と接続文字列を正常に扱えるように修正されました。  (David Fetter, Andrew Dunstan, &Aacute;lvaro Herrera) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
本構文はドキュメント化されていませんが、永らく受け入れられてきました。本修正でドキュメント記載されました。
</p>
<p>
本構文を使った場合に、一部のパラメータで与えられた値でなく旧の接続の値が使われる誤りがあり、修正されました。
</p>
<pre>
(本構文の実行例)
postgres=# connect "dbname=db1 user=postgres"
You are now connected to database "db1" as user "postgres".
db1=# c postgresql://localhost:5432/db2
You are now connected to database "db2" as user "postgres" on host "localhost"
at port "5432".
db2=#
</pre>
<li>一部プラットフォームにおいて、終了時に ~/.psql_history を書くのに失敗した、という psql の誤ったメッセージを抑止するようになりました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
この誤動作は 2006 年以前の古いバージョンの libedit の障害を回避するために生じていました。回避策のコードを除去することで修正しました。そのため、古い libedit では再び問題が生じます。libedit をバージョンアップをするか、libreadline を使うことを推奨します。
</p>
<li>pg_dump にて、システム提供されたダンプ不要のキャストを判断する規則が修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
キャスト名が「pg_」で始まっているかではなく、キャストの OID で判断するようになりました。
</p>
<li>pg_dump で -Fd が指定されたとき -Z で指定した圧縮レベルを尊重するように修正されました。  (Michael Paquier) (9.4)(9.3)(9.2)(9.1)</li>
<p>
修正前には常にデフォルト圧縮レベルになっていました。
</p>
<li>pg_dump がダンプ順序の選択において、拡張モジュールの設定テーブル間の外部キー関係を考慮するようになりました。  (Gilles Darold, Michael Paquier, Stephen Frost) (9.4)(9.3)(9.2)(9.1)</li>
<p>
本修正前では、一過性の外部キー制約違反によりダンプ読み込み失敗をひき起こすことがありました。
</p>
<li>同時実行で一時関数の作成削除をしている場合に pg_dump が失敗する可能性があり、これを防ぐようになりました。  (Tom Lane) (9.4)(9.3)</li>
<li>定義が VALUES (...) だけでカラム別名を持つビューのダンプが修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
これまで、ダンプ内容からカラム名が欠落してしまっていました。
</p>
<li>ダンプ／リストアでビューのレプリケーション識別(pg_class.relreplident) が確実に正しく 'n' (REPLICA_IDENTITY_NOTHING) になるように修正されました。  (Marko Tiikkaja) (9.4)</li>
<p>
これまで、ビューが循環依存している場合、レプリケーション識別属性がおかしくなることがありました。
</p>
<li>pg_upgrade で新データベースクラスタのタイムラインを強制的に 1 にするようになりました。  (Bruce Momjian) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
この変更は、WALヒストリファイルが無いという誤ったエラーによるアップグレード失敗を防ぎます。
</p>
<li>pg_upgrade で不適切な接続不能データベースが無いか検査するようになりました。  (Bruce Momjian) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<li>pg_upgrade で生成される delete_old_cluster スクリプトの中でディレクトリパスを適切にクオートするようになりました。  (Bruce Momjian) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<li>pg_upgrade でデータベースレベルの凍結情報を適切に保持するようになりました。  (Bruce Momjian) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
postgres データベースと template1 データベースにて pg_database.datfrozenxid と pg_database.datminmxid が維持されていませんでした。アップグレード後、これらデータベース上のテーブルやインデックスにアクセスすると、pg_clog 下のファイルが無いというエラーをひき起こしていました。
</p>
<li>Windows 上で pg_upgrade と pg_resetxlog を制限された権限で実行するようになりました。  (Muhammad Asif Naeem) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
これにより、Administratorユーザから実行されても失敗しなくなります。これまで「Permission denied」が出て失敗するケースが報告されていました。
</p>
<li>initdb と pg_basebackup でディレクトリを読み取るときに readdir() が失敗した場合の扱いが改善されました。  (Marco Nenciarini) (9.4)(9.3)(9.2)(9.1)</li>
<p>
readdir()システムコールが設定する errno 変数値が失われないように修正されました。エラーメッセージに失敗理由が正しく表示されるようになります。
</p>
<li>contrib/intarray モジュールの遅いソートアルゴリズムが修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
これまでは挿入ソートで実装されていて、最大で  O(N^2) の処理時間を必要としていました。クイックソートで置き換えられました。
</p>
<li>SPARC V8 機でのコンパイル失敗が修正されました。  (Rob Rowan) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<li>OS X でビルドする際のいくつかの警告が出なくなりました。  (Tom Lane) (9.4)(9.3)</li>
<li>タイムゾーンデータファイルが tzdata release 2015d に更新されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
エジプト、モンゴル、パレスチナにおける夏時間規則の変更、カナダ、チリの歴史的変更、America/Adak の時間帯省略形の改定（HAST/HADT でなく HST/HDT となる）が、適用されています。
</p>
<li>pg_receivexlog の障害が修正されました。  (Andres Freund) (9.2)</li>
<p>
9.2.10 で障害が入りこみ、エラー「could not create archive status file」をひき起こしていました。
</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.1.15 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/9-1-15/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Thu, 05 Feb 2015 01:01:23 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 9.1]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=2223</guid>

					<description><![CDATA[このリリースは 9.1.14 からの修正リリース(2015/2/5リリース)です。 9.1.x からのアップデートではダンプ、リストアは不要です。 また、9.1.14 より前のバージョンからアップデートを行う場合は 9. ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 9.1.14 からの修正リリース(2015/2/5リリース)です。<br />
9.1.x からのアップデートではダンプ、リストアは不要です。</p>
<p>また、9.1.14 より前のバージョンからアップデートを行う場合は <a href="/tech-blog/pgsql/9-1-14/">9.1.14 に関する技術情報</a>を参照してください。</p>
<p><span id="more-2223"></span></p>
<h3 class="background">PostgreSQL 9.1.14 から 9.1.15 への変更点</h3>
<p>9.4.1、9.3.6、9.2.10、9.1.15、9.0.19 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<hr />
<ol class="technology">
<li>to_char() 関数のバッファオーバーランが修正されました。  (Bruce Momjian) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
桁数の大きい数値を書式整形するとき、バッファ終端を超えた場所を読み取ってしまうことがありえました。また、作りこまれたタイムスタンプ出力書式において、バッファ終端を超えた位置に書き込むことがあえりました。どちらの場合もバックエンドプロセスのクラッシュを引き起こします。本障害を利用した攻撃での権限昇格の可能性も排除できません。
</p>
<p>
本セキュリティ障害は CVE-2015-0241 として登録されています。
</p>
<li>内部的に使われる *printf() 置き換え関数群でバッファオーバーランが修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
PostgreSQL 実装には printf などの置き換え関数が含まれています。その中で浮動小数点値の整形（指定子 'e'、'E'、'f'、'F'、'g'、'G'）をおよそ 500 以上の精度を指定して行うとき、スタックのバ<br />
ッファオーバーランが生じ、バックエンドプロセスのクラッシュをひき起こします。本障害を利用した攻撃での権限昇格の可能性も排除できません。PostgreSQLコア機能の他、printf族を利用している拡張モジュールにも影響があります。
</p>
<p>
本障害は主として Windows 上で影響があります。Windows においてこれらの置き換え関数が使用されます。 PostgreSQL は適切なシステム実装がある場合には、置き換え関数群でなく、システム実装の関数を使用します。
</p>
<p>
本セキュリティ障害は CVE-2015-0242 として登録されています。
</p>
<li>拡張モジュール contrib/pgcrypto のバッファオーバーランが修正されました。  (Marko Tiikkaja, Noah Misch) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
pgcrypto モジュールにてメモリサイズ追跡の誤りにより、スタックのバッファオーバーランと未初期化メモリ内容への依存が生じる余地がありました。本バッファオーバーランはバックエンドプロセスのクラッシュをひき起こします。本障害を利用した攻撃での権限昇格の可能性も排除できません。
</p>
<p>
本セキュリティ障害は CVE-2015-0243 として登録されています。
</p>
<li>エラー後に PostgreSQLプロトコルの同期が失われる可能性があり、修正されました。  (Heikki Linnakangas) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
バックエンドプロセスがクライアントからのメッセージを読んでいる途中に何らかエラーが起きた場合、同期が失われ、メッセージの一部分を新たなメッセージとして解釈しようと誤って試みられます。この障害により、攻撃者がコマンドパラメータ中に作りこまれたバイナリデータを送り出すことで、SQL インジェクションを実現できる可能性がありました。
</p>
<p>
本障害ケースをひき起こす「プロトコル処理途中でのエラー」は、代表的には、ステートメントタイムアウトや問い合わせのキャンセルです。タイムアウトを使用していて、かつ、任意のユーザ作成バイナリデータをクエリパラメータで渡せるアプリケーションにおいて、特に脆弱性が生じます。ステートメントタイムアウトを使わないことで完全ではありませんがリスクを軽減できます。
</p>
<p>
本セキュリティ障害は CVE-2015-0244 として登録されています。
</p>
<li>制約違反エラーメッセージを通した情報漏洩が修正されました。  (Stephen Frost) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
ユニーク制約違反など、いくつかのサーバエラーメッセージで制約違反した値を出力しています。ユーザが SELECT 権限を持たないとすれば、見ることができないはずの値が見えてしまうことになります。
</p>
<p>
本セキュリティ障害は CVE-2014-8161 として登録されています。
</p>
<pre>
(権限のあるユーザでエラーを出すと、従来通り値も表示される)
db1=# INSERT INTO t1 VALUES (0, 'XX'), (1, 'XX'), (2, 'XX');
ERROR:  duplicate key value violates unique constraint "t1_pkey"
DETAIL:  Key (id)=(1) already exists.

(INSERT 権限はあっても SELECT 権限のないユーザでは、値が表示されないようになる)
db1=&gt; SELECT * FROM t1;
ERROR:  permission denied for relation t1

db1=&gt; INSERT INTO t1 VALUES (0, 'XX'), (1, 'XX'), (2, 'XX');
ERROR:  duplicate key value violates unique constraint "t1_pkey"
</pre>
<li>Windows 上で回帰テスト用の一時的なインスタンスへのアクセスが制限されました。  (Noah Misch) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
SSPI 認証を使うことでテストを起動した OS ユーザのみが接続できるようになりました。これまで他のユーザがテスト中の PostgreSQL に接続することができました。
</p>
<p>
本セキュリティ障害は CVE-2014-0067 として登録されています。
</p>
<li>Windows ロケール名「Norwegian (Bokm&aring;l)」に対応しました。  (Heikki Linnakangas) (9.4)(9.3)(9.2)</li>
<p>
非アスキー文字のロケール名はエンコーディングが定まらないと判別できない問題があります。「Norwegian (Bokm&aring;l)」は、ASCII 文字だけで表現される別名「Norwegian_Norway」にマップされます。9.4.0 では「norwegian-bokmal」にマップしていましたが、これは全ての Windows で利用可能な名称ではありませんでした。
</p>
<li>EvalPlanQual処理で解放済みメモリを参照してしまう障害が修正されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
EvalPlanQual処理は、READ COMMITTED トランザクション隔離モードでの行の削除・更新・ロックで使われる内部的な仕組みです。
</p>
<p>
READ COMMITTED トランザクション隔離モードで、行ロックまたは UPDATE を最近更新した行に対して行うとき、バックエンドプロセスがクラッシュする可能性がありました。
</p>
<li>行ロック取得を試みるときの EvalPlanQual処理においてデッドロックになる可能性があり、修正されました。  (&Aacute;lvaro Herrera, Mark Kirkwood) (9.4)(9.3)</li>
<li>複数の他トランザクションが同時に FOR SHARE 行ロックを保持している中で、トランザクションが FOR NO KEY UPDATE 行ロックの取得を試みて待つのに失敗してしまう障害が修正されました。  (&Aacute;lvaro Herrera) (9.4)(9.3)</li>
<p>
後からの FOR NO KEY UPDATE 行ロックの取得で、本来ブロックされるべきところ、取得できてしまう動作ケースがありました。
</p>
<li>テーブルやカラムが多数あるクエリに対する EXPLAIN の性能が改善されました。  (Tom Lane) (9.4)(9.3)</li>
<li>jsonb データ型における Unicode エスケープについて修正され、結論として u0000 は使用できなくなりました。  (Tom Lane) (9.4)</li>
<p>
9.4.0 バージョンでは JSON の Unicode エスケープ「u0000」は受け付けられ6文字のデータとして格納されていました。このことは「\u0000」が入力された場合と区別がつかず、さらに、-&gt;&gt; 演算子などで文字列型に変換して出力するときに「u0000」とエスケープを残した形で出力され、一貫性に欠けた振る舞いになります。一方で PostgreSQL は文字列に x00 を含めることができません。
</p>
<p>
jsonb型への入力で「u0000」は受け付けないものとなりました。既に格納されているデータは「\u0000」が格納されているものとして扱われます。
</p>
<p>
json型では引き続き「u0000」の格納を受け付けます。これは、たとえデータベース文字エンコーディングが UTF8 でなくとも 非ASCII の Unicode エスケープを受け付けるのと同じことです。ただし、テキスト出力時の例外処理は無くなります。
</p>
<pre>
db1=# SELECT '["u0041"]'::json -&gt;&gt; 0;
 ?column?
----------
 A
(1 row)

(9.4.0 の場合)

db1=# SELECT '["u0000"]'::jsonb -&gt;&gt; 0; -- 例外的な出力になる
 ?column?
----------
 u0000
(1 row)

(9.4.1 の場合)

db1=# SELECT '["u0000"]'::jsonb;            -- jsonb型には格納も不可
ERROR:  unsupported Unicode escape sequence

db1=# SELECT '["u0000"]'::json;             -- json型なら格納はできる
    json
------------
 ["u0000"]
(1 row)

db1=# SELECT '["u0000"]'::json -&gt;&gt; 0;  -- テキスト出力ではエラーになる
ERROR:  unsupported Unicode escape sequence
DETAIL:  u0000 cannot be converted to text.
</pre>
<li>xpath() 関数の名前空間の扱いが修正されました。  (Ali Akbar) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
これまで、xpath() 呼び出しから返される XML値は、入力 XML値の祖先要素に名前空間宣言が付加されていたとしても、名前空間宣言を持ちませんでした。修正で祖先要素の宣言が反映されるようになりました。
</p>
<pre>
db1=# SELECT xpath('//loc:piece',
 $$
 &lt;local:data xmlns:local="http://127.0.0.1/"&gt;
  &lt;local:piece id="1"&gt;number one&lt;/local:piece&gt;
  &lt;local:piece id="2" /&gt;
 &lt;/local:data&gt;
 $$,
 ARRAY[ARRAY['loc', 'http://127.0.0.1/']]);

(修正前の応答)
                                    xpath
------------------------------------------------------------------------------
 {"&lt;local:piece id="1"&gt;number one&lt;/local:piece&gt;","&lt;local:piece id="2"/&gt;"}
(1 row)

(修正後の応答)
                                                                    xpath
------------------------------------------------------------------------------------------------------------------------------------------------
 {"&lt;local:piece xmlns:local="http://127.0.0.1/" id="1"&gt;number one&lt;/local:piece&gt;","&lt;local:piece xmlns:local="http://127.0.0.1/" id="2"/&gt;"}
(1 row)
</pre>
<li>範囲演算子の選択率見積で、いくつか軽微な誤りが修正されました  (Emre Hasegeli) (9.4)(9.3)</li>
<p>
プランナエラー「ERROR: unexpected operator NNNN」の発生が修正されます。また、そのほかのいくつかのケースで選択率の見積が改善されます。
</p>
<pre>
(修正前のエラーを起こす例)
db1=# CREATE TABLE t_nr (nr numrange);
db1=# SELECT * FROM t_nr WHERE nr &lt; 'empty';
ERROR:  unexpected operator 3884
</pre>
<li>意図しない GIN インデックスの要素最大サイズの引き下げが元に戻されました。  (Heikki Linnakangas) (9.4)</li>
<p>
9.4.0 では、以前のバージョンでは受け入れられていたデータに対して、「ERROR: index row size &#x301C;  exceeds maximum &#x301C;」エラーが出ることがありました。
</p>
<pre>
(以下は 9.4.0 でエラーになりますが 9.4.1 では INSERT 可能です)

db1=# CREATE TABLE t_gin (tags text[]);
db1=# CREATE INDEX ON t_gin USING gin (tags);
db1=# INSERT INTO t_gin VALUES (ARRAY[repeat('a', 120000)]);
ERROR:  index row size 1400 exceeds maximum 1352 for index "t_gin_tag_idx"
</pre>
<li>GIN インデックスのスキャン繰り返しで、一つのクエリ実行の間のメモリリークがあり、修正されました。  (Heikki Linnakangas) (9.4)</li>
<li>gin_fuzzy_search_limit 設定パラメータにゼロ以外を設定したとき、バックエンドプロセスのクラッシュをひき起こすことがあり、修正されました。  (Heikki Linnakangas) (9.4)</li>
<li>ロジカルデコーディング機能についていくつか修正されました。  (Andres Freund) (9.4)</li>
<li>パラメータ変更をする WALレコードのリプレイが修正されました。  (Petr Jalinek) (9.4)</li>
<p>
wal_log_hints の設定変更が正しくリプレイされませんでした。
</p>
<li>実行時統計情報収集のタイムアウトのログレベルが WARNING から LOG に変更されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
メッセージも「WARNING:  pgstat wait timeout」から、より丁寧な「LOG:  using stale statistics instead of current ones because stats collector is not responding」というものになります。
</p>
<li>OS X (Darwin) の setlocale() ライブラリ関数が PostgreSQL マスタプロセス内で新たにスレッドを起動する場合に警告とヒントを出すようになりました。  (Noah Misch) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
マルチスレッド化すると内部的なシグナル処理で不具合が生じる可能性があります。LC_ALL 環境変数に有効なロケールを設定しておくことが回避策となります。
</p>
<p>
「LOG:  postmaster became multithreaded during startup」「HINT: Set the LC_ALL environment variable to a valid locale.」というメッセージが出力されるようになります。
</p>
<li>/etc/passwd が読めないときの libpq の振る舞いが修正されました  (Tom Lane) (9.4)</li>
<p>
PQsetdbLogin() 関数を実行するとき、libpq は OS 上のユーザ名を確認しようとします。ほとんどの UNIX プラットフォームでは /etc/passwd が参照されます。
</p>
<p>
9.4.0 では /etc/passwd が読めない場合には常にエラーとして扱っていましたが、従来の、データベースロール名が明示されない場合のみエラーにするという振る舞いに戻されました。これにより chroot されて /etc/passwd がない環境に対応します。
</p>
<li>psql 特別変数の値の解析が一貫性を持つように改善されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
ECHO_HIDDEN と ON_ERROR_ROLLBACK で on 、off を様々な書き方で与えることができるようになりました（1、0、true、false など）。
</p>
<p>
COMP_KEYWORD_CASE 、ECHO 、ECHO_HIDDEN 、HISTCONTROL 、ON_ERROR_ROLLBACK 、および VERBOSITY で、解釈できない値について警告がでるようになりました。
</p>
<p>
全ての特別変数の値について大文字小文字の区別なく受け付けるようになりました。これまでは区別があるもの、ないものが混在していました。
</p>
<li>pg_dump でイベントトリガーに対するコメントのダンプに失敗していたのが修正されました。  (Tom Lane) (9.4)(9.3)</li>
<pre>
(失敗例)
db1=# COMMENT ON EVENT TRIGGER my_event_trg IS 'comment of event trigger';
db1=# q
$ pg_dump db1 > db1.dump
cannot duplicate null pointer (internal error)
</pre>
<li>pg_dump で並列実行する --jobs (-j) オプションとともに--serializable-deferrable オプションが利用可能になりました。  (Kevin Grittner) (9.4)(9.3)</li>
<p>
これまではエラーとなっていました。
</p>
<li>pg_basebackup の -x / -X オプションで作られた WALファイルが、昇格した際に再度アーカイブされないように修正されました。  (Andres Freund) (9.4)(9.3)(9.2)(9.1)</li>
<p>
これまで -x / -X オプションで取得した WAL ファイルは未アーカイブの扱いになっていました。wal_keep_segment 設定等でオンライン WAL ファイル数が多いとき、昇格後これらをアーカイブするのに時間を要していました。
</p>
<li>contrib/tablefunc の connectby() 関数で、予想外のクエリ結果、特に NULLを安全に扱えるようになりました。  (Michael Paquier) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
これまで keyid カラムに NULL があるときクラッシュしていました。
</p>
<li>Coverity の静的コード解析の警告に基づき多数の修正が行われました。  (Andres Freund, Tatsuo Ishii, Marko Kreen, Tom Lane, Michael Paquier) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
ほとんどは表面的な変更ですが、一部においてまれな障害ケースも修正されています。メモリ不足で失敗した際に適切なエラーを出さず、クラッシュしてしまう個所がありました。セキュリティ問題はないものと考えられます。
</p>
<li>configure 実行時の環境変数 CFLAGS で自動設定される値を上書きできるようになりました。  (Tom Lane) (9.4)</li>
<p>
これまでは configure スクリプトにより CFLAGS の末尾にオプションが追記され、コンパイラが先頭から解釈するために、ユーザ定義した内容を上書きしていました。あらかじめ CFLAGS に設定してあった文字列を末尾に置くようになりました。
</p>
<pre>
(従来)
CFLAGS="{あらかじめCFLAGSに設定してあった内容}  {configureで付加される内容} "
(修正後)
CFLAGS="{configureで付加される内容}  {あらかじめCFLAGSに設定してあった内容} "
</pre>
<li>pg_regress が成功終了時には作成する一時インスタンスのファイルを全て削除するようになりました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<li>タイムゾーン省略名 CST (China Standard Time) が追加されました。  (Tom Lane) (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
9.3 以前のバージョン系列では、ADT (Arabia Daylight Time) の削除、CKT (Cook Islands)、FJT、FJST (Fiji) のオフセットの修正も行われています。これらは 9.4.0 時点で適用済みでした。
</p>
<li>タイムゾーンデータが tzdata release 2015a に更新されました。   (9.4)(9.3)(9.2)(9.1)(9.0)</li>
<p>
チリ、メキシコの夏時間法が変更され、アイスランドの歴史的変更が適用されています。
</p>
<p>
9.3 以前のバージョン系列では、オーストラリアのタイムゾーンに略記法 AxST/AxDT を採用、そのほか略記法に SERT (Asia/Srednekolymsk) 、XJT (Asia/Urumqi)、WSST/WSDT (西サモア) を追加、Pacific/Bougainville タイムゾーン追加、という変更が適用さ<br />
れています。これらは tzdata release 2014j での更新内容で、9.4.0バージョンで既に適用されていました。
</p>
<li>ALTER DATABASE .. SET TABLESPACE でデータベースのテーブルスペースを移動して、そのあとすぐに元のテーブルスペースに戻すときにデータ破損の可能性があり、修正されました。  (Tom Lane) (9.3)(9.2)(9.1)(9.0)</li>
<li>トランザクション内で DDL と共に ANALYZE を実行してロールバックするときのテーブル破損を回避するように修正されました。  (Andres Freund, Tom Lane, Michael Paquier) (9.3)(9.2)(9.1)(9.0)</li>
<p>
トランザクション内で ANALYZE に先だってインデックス削除、ルール削除、（制約を含む）トリガー削除を行う場合に該当します。
</p>
<li>UNLOGGEDテーブルが CREATE DATABASE や ALTER DATABASE .. SET TABLESPACE で確実に正しくコピーされるように修正されました。  (Pavan Deolasee, Andres Freund) (9.3)(9.2)(9.1)</li>
<p>
これらコマンドで UNLOGGEDテーブルについてもストレージ同期処理が行われるようになりました。
</p>
<p>
本障害により、テーブルスペース移動後のチェックポイント処理にて、以下メッセージ出て失敗するケースが報告されていました。
</p>
<pre>
ERROR:  checkpoint request failed
ERROR:  could not open file "pg_tblspc/16543/PG_9.3_201411111/16555/16666": No such file or directory
</pre>
<li>CREATE EVENT TRIGGER コマンドの実装誤りが修正されました。  (Petr Jelinek) (9.3)</li>
<p>
本コマンドをプリペアドクエリまたは拡張プロトコルで実行するときに、正しく動作しませんでした。
</p>
<li>テーブルのカラムが再帰的に参照される場合の DROP コマンドの依存性確認動作が修正されました。  (Petr Jelinek, Tom Lane) (9.3)(9.2)(9.1)</li>
<p>
拡張モジュールがデータ型とそのデータ型を使ったテーブルの両方を定義する場合に該当します。これまで CASCADE を付けない DROP EXTENSION が不必要に失敗することがありました。
</p>
<li>部分インデックスが子テーブルにあるときの SELECT .. FOR UPDATE に対する実行プランが修正されました。  (Kyotaro Horiguchi) (9.3)(9.2)(9.1)(9.0)</li>
<p>
READ COMMITED トランザクションモードでの SELECT .. FOR UPDATE を継承を伴う親テーブルに対して行い、その子テーブルの部分インデックスが使われる場合に、本障害で誤った結果行が返る可能性がありました。
</p>
<li>継承テーブルに対して SELECT .. FOR UPDATE が同じ行を２回返すことがあり、修正されました  (Tom Lane) (9.3)(9.2)(9.1)(9.0)</li>
<p>
READ COMMITTED トランザクションモードで継承テーブル（親テーブル）に対して SELECT .. FOR UPDATE を行うとき、次の子テーブルの行を返すべきところで誤って手前の子テーブルの行を返してしまうことがありえました。
</p>
<li>外部キー制約定義で重複したカラム名を受け入れないようになりました。  (David Rowley) (9.3)(9.2)(9.1)(9.0)</li>
<p>
この制限は SQL標準にしたがったものです。これまでは明確に排除していませんでしたが、後で奇妙なエラーが生じていました。
</p>
<pre>
(修正後バージョンで以下のエラーが出るようになります)
db1=# CREATE TABLE t_mas (id int primary key);
db1=# CREATE TABLE t_ref (id int PRIMARY KEY REFERENCES t_mas (id, id));
ERROR:  foreign key referenced-columns list must not contain duplicates
</pre>
<li>「SELECT .. OFFSET -1」がエラーになるように修正されました。  (Tom Lane) (9.3)</li>
<p>
PostgreSQL 8.4 以降からは OFFSET に負値を与えるとエラーになるのが本来の動作でしたが、9.3 バージョン系列では OFFSET 指定が無いものとして、SELECT が動作してしまっていました。
</p>
<li>ドメインを JSON に変換するときの振る舞いが元に戻されました。  (Tom Lane) (9.3)(9.2)</li>
<p>
numeric型および boolean型に対するドメインのデータを変換するときに、ベース型と同じ扱いで変換するようになります。
</p>
<p>
9.3.5 以前、9.2.9 以前のバージョンではそのように動作していましたが、関連する別の問題を修正する際に振る舞いが変ってしまっていました。
</p>
<pre>
(動作例)
db1=# CREATE DOMAIN d_numeric AS numeric ;
db1=# CREATE DOMAIN d_boolean AS boolean ;
db1=# CREATE TABLE tc (b1 boolean, n1 numeric);
db1=# CREATE TABLE td (b1 d_boolean, n1 d_numeric);
db1=# INSERT INTO tc VALUES (true, 100);
db1=# INSERT INTO td VALUES (true, 100);
db1=# SELECT row_to_json(tc.*) FROM tc;
     row_to_json
----------------------
 {"b1":true,"n1":100}
(1 row)

(9.3.5 / 9.2.9 の場合)
db1=# SELECT row_to_json(td.*) FROM td;
      row_to_json
-----------------------
 {"b1":"t","n1":"100"}
(1 row)

(9.3.6 / 9.2.10 の場合)
db1=# SELECT row_to_json(td.*) FROM td;
     row_to_json
----------------------
 {"b1":true,"n1":100}
(1 row)
</pre>
<li>json_agg() 関数が末尾に余計な右ブラケット(])付けてを返さないように修正されました。  (Tom Lane) (9.3)</li>
<li>整数べき乗計算の誤りが修正されました。  (Tom Lane) (9.3)(9.2)(9.1)(9.0)</li>
<p>
大きいべき乗数を与えた場合に、誤った答えが返ったり、オーバーフローと判別するまでに大量にメモリを消費して長時間を要することがありました。
</p>
<pre>
(障害動作例：以下２つはゼロかゼロに非常に近い値が返るはず)

db1=# SELECT 10.0 ^ -2147483648;
   rounds_to_zero
--------------------
 1.0000000000000000
(1 row)

db1=# SELECT 10.0 ^ -2147483647;
ERROR:  division by zero

(以下は「ERROR:  value overflows numeric format」とならなければいけない)
db1=# SELECT 10.0 ^ 2147483647 ;
     overflows
--------------------
 0.0000000000000000

db1=# SELECT 117743296169.0 ^ 1000000000 ;
 ... 長時間応答なし

</pre>
<li>NUMERICデータ型のバイナリ入力関数 numeric_recv() で表示桁数属性にしたがえば見えない微小桁を切り捨てるようになりました。  (Tom Lane) (9.3)(9.2)(9.1)(9.0)</li>
<p>
クライアントからバイナリデータで投入された numeric 値で、表示される桁より小さな桁の値が保持されていて、値の演算を経て顕在化する奇妙な動作がありました。
</p>
<li>正規表現の最短一致の誤りが修正されました。  (Tom Lane) (9.3)(9.2)</li>
<p>
最短一致指定を付けた場合にマッチに失敗することがありました。
</p>
<pre>
(修正前の障害動作例：最短一致指定で + の後の ? を付けるとマッチしない)
db1=# SELECT regexp_matches('foo/bar/baz',
               '^([^/]+)(?:/([^/]+))(?:/([^/]+))?$', '');
 regexp_matches
----------------
 {foo,bar,baz}
(1 row)

db1=# SELECT regexp_matches('foo/bar/baz',
                '^([^/]+?)(?:/([^/]+?))(?:/([^/]+?))?$', '');
 regexp_matches
----------------
(0 rows)
</pre>
<li>数値による timezone 設定値の指定で範囲外の値を拒絶するようになりました。  (Tom Lane) (9.3)(9.2)(9.1)(9.0)</li>
<p>
timezone に +/- 168時間を超える値を指定可能でしたが、タイムゾーン処理時にクラッシュをひき起こしていました。+/- 167 までに制限されるようになります。
</p>
<pre>
(修正前の障害動作例)
db1=# SET timezone TO '+300';
SET
db1=# SELECT '2015-02-11'::timestamptz;
server closed the connection unexpectedly
(ここでバックエンドクラッシュ)
</pre>
<li>演算子「tsquery @&gt; tsquery」の障害が修正されました。  (Heikki Linnakangas) (9.3)(9.2)(9.1)(9.0)</li>
<p>
語の一致を CRC 計算値のみで判断していたため、偶然 CRC が一致した異なる語があるとき誤った結果が返っていました。
</p>
<p>
また、右辺の要素の方が多い場合にはマッチしないものとする動作でしたが、語の重複を考慮すると適切な振る舞いではありませんでした。
</p>
<pre>
(以下は修正前バージョンでは f 、修正後バージョンで t となります)
db1=# SELECT to_tsquery('aaa,bbb') @&gt; to_tsquery('aaa,bbb,aaa');
</pre>
<li>全文検索で Ispell辞書を作る際に接辞ファイル(AffFile) に指定したファイルが不適切である場合にクラッシュしないように修正されました。  (Tom Lane) (9.3)(9.2)(9.1)(9.0)</li>
<li>全文検索の類語辞書にて、一つのエントリに 65536 以上の語句を指定できるようになりました。  (David Boutin) (9.3)(9.2)(9.1)(9.0)</li>
<li>行全体の変数値と複合引数の処理が修正されました。  (Tom Lane) (9.3)(9.2)</li>
<p>
行全体の値が空のカラム名を関数に出さないように修正されました。
</p>
<p>
「SELECT row_to_json(tab.*) ...」などを実行した際に予期せぬエラー「ERROR: record type has not been registered」が生じることがありました。
</p>
<li>postgres_fdw のクエリでシステムカラムの扱いについて修正されました。  (Etsuro Fujita) (9.3)(9.2)</li>
<p>
tableoid などの ctid 以外のシステムカラムについて、リモート側でなく呼び出し側で処理するようになりました。
</p>
<li>インデックスの付いたカラムに対して「col = ANY ( array ) 」を実行する際に劣ったプランになるのを避けるようになりました。   (Andrew Gierth) (9.3)(9.2)</li>
<p>
これまで「Filter: (col = ANY (...))」が有利な場合でも、「Index Cond: (col = ANY (...))」が使われることがあり、修正されました。
</p>
<p>
なお「col IN (101, 102, 103) 」のような式も「col = ANY ('{101,102,103}'::integer[])」などと変換されて実行されますので該当します。
</p>
<li>「ERROR: variable not found in subplan target lists」メッセージが出る障害が修正されました。 (Tom Lane) (9.3)</li>
<p>
複合引数を取りインライン展開される SQL関数が、LATERAL 副問い合わせで使われる場合や、その複合引数が LATERAL参照である場合に発生します。
</p>
<li>UNION ALL のサブクエリ内における継承テーブルのように、入れ子で Append 処理が行われる場合のプランナの問題が修正されました。  (Tom Lane) (9.3)(9.2)(9.1)(9.0)</li>
<p>
バックエンドクラッシュをひき起こすことがありました。
</p>
<li>GiST インデックス要素がページに適合していない場合に正常にエラーを出すように修正されました。  (Andrew Gierth) (9.3)(9.2)(9.1)(9.0)</li>
<p>
サイズの大きい要素の投入に対して、無限再帰処理からのバックエンドクラッシュが生じていました。
</p>
<li>自動VACUUM でテーブル毎の cost_limit、cost_delay 指定がある場合、グローバルなこれらコストバランス規則からは除外するようになりました。  (&Aacute;lvaro Herrera) (9.3)(9.2)(9.1)(9.0)</li>
<p>
これまでは、結果としてテーブル毎のこれら設定が無視されていました。本修正により、テーブル毎コスト設定がある場合には、他の autovacuum workerプロセスとは独立に休止の処理が行われるようになり、指定値が反映されます。
</p>
<p>
本変更により、同じ設定であればより休止が少なくなり、I/O 負荷が以前より高まることになります。
</p>
<li>autovacuum = off であるとき、大規模な自動VACUUM 処理を回避するようになりました。  (Tom Lane) (9.3)(9.2)(9.1)(9.0)</li>
<p>
autovacuum = off であっても、XID 周回対策処理が必要であるときには、自動VACUUM が実行される仕様です。このときの対象データベースの全テーブルに通常の自動VACUUM 処理が行われていました。これは、XID 周回の脅威への対応を遅らせることにもなっていました。
</p>
<p>
本修正により、autovacuum = off であるときには、XID 周回対策処理だけを自動で行うようになりました。
</p>
<li>クラッシュリカバリ中、リカバリが完了する前に、UNLOGGED テーブルを空にしてディスク同期するようになりました。  (Abhijit Menon-Sen, Andres Freund) (9.3)(9.2)(9.1)</li>
<p>
これにより、クラッシュリカバリ後に UNLOGGED テーブルにゴミデータが含まれることを防ぎます。
</p>
<li>ホットスタンバイのクエリと、フルページイメージのリプレイの競合状態が修正されました。  (Heikki Linnakangas) (9.3)(9.2)(9.1)(9.0)</li>
<p>
この不具合はホットスタンバイでのクエリ実行で一時的なエラー、あるいは、誤った実行結果（行の欠損）をもたらすことがありました。
</p>
<li>COMMIT/ABORT PREPARED の WALレコードを不適切に無視するリカバリロジックがいくつか修正されました。  (Heikki Linnakangas) (9.3)(9.2)(9.1)(9.0)</li>
<p>
pg_last_xact_replay_timestamp() 関数、recovery_target_xid 設定において 2相コミットの PREPARED 処理の WAL レコードが無視されていました。なお、9.4 系列においては recovery_min_apply_delay 設定でも無視されていましたが、9.4.0 にて既に修正が<br />
適用済みです。
</p>
<li>クラッシュリカバリ完了時に、最新のWALファイルが再度アーカイブされないように修正されました。  (Fujii Masao) (9.3)(9.2)</li>
<li>タイムラインヒストリファイルに必要のない .ready マーカーファイルが作成されないように修正されました。  (Fujii Masao) (9.3)(9.2)(9.1)(9.0)</li>
<p>これまでは旧タイムラインのアーカイブからリストアした WALファイルであってもリカバリ時に常に .ready ファイルが作られていました。</p>
<li>log_statement が mod もしくは ddl で、空のプリペアドステートメントが使用されたときにヌルポインタ参照が起こらないように修正されました。  (Fujii Masao) (9.3)(9.2)(9.1)(9.0)</li>
<li>マスタプロセスの動的バックグラウンドワーカーのリストが破損する可能性があり、修正されました。  (Andres Freund) (9.3)
</li>
<p>
9.4.0 リリース前時点の9.4系列で問題が発見され、9.3.6 でも同様の修正が適用されました。
</p>
<li>いくつかのnon-Solaris カーネルがそうするように SPARC のスピンロックをCPU が non-TSO コヒーレンシーモードでの正確な動作を保証するように修正されました。  (Andres Freund) (9.3)(9.2)(9.1)(9.0)</li>
<li>PQconnectdbParams() 関数で dbname パラメータが繰り返されたときの処理が修正されました。  (Alex Shulgin) (9.3)(9.2)(9.1)(9.0)</li>
<p>
dbname が接続文字列かURIに含まれていた時、予期しない振る舞いをすることがありました。
</p>
<li>libpq が報告する予期しないソケットのEOFに関するメッセージを適切なものにしました。  (Marko Tiikkaja, Tom Lane) (9.3)(9.2)(9.1)(9.0)</li>
<p>
カーネルの振る舞いに従うと、libpq はサーバが予期せずソケットが閉じたときに有用なエラーを返さずに、空のエラー文字列を返してしまうことがありました。
</p>
<li>PQreset() 関数実行中の古いエラーメッセージが消去されるようになりました。  (Heikki Linnakangas) (9.3)(9.2)(9.1)(9.0)</li>
<p>
PQreset() 関数が何度も呼ばれて接続が再確立できなかったとき、失敗した接続によるエラーメッセージは PGconn のエラー文字列に蓄積し続けていました。
</p>
<li>libpq 接続オプションの構文解析におけるメモリ不足状態を適切に扱えるようになりました。  (Alex Shulgin, Heikki Linnakangas) (9.3)(9.2)(9.1)(9.0)</li>
<p>
これまで接続クライアント側でクラッシュが生じることがありました。
</p>
<li>ParseDateTime() 関数の ecpg バージョンにおける配列オーバーランが修正されました。  (Michael Paquier) (9.3)(9.2)(9.1)(9.0)</li>
<p>
本障害箇所が攻撃に使われる恐れは無いものと考えられます。
</p>
<li>initdb 実行時、パスワードファイルが指定されているにも関わらずその内容が空の場合、エラーメッセージを明示的に出力するようになりました。  (Mats Erik Andersson) (9.3)(9.2)(9.1)(9.0)</li>
<p>
以前も空のパスワードファイルである場合には initdb は失敗していましたが、エラーメッセージが明快ではありませんでした。
</p>
<pre>
(以前のメッセージ例)
$ initdb -D ./pgdata --pwfile empty.pass
The files belonging to this database system will be owned by user "postgres".
 (中略)
initdb: could not read password from file "empty.pass": Success
initdb: removing data directory "./pgdata"
</pre>
<li>最近の libedit を利用している psql の s コマンドがうまく働くようになり、ページャのサポートが付加されました。  (Stepan Rutz, Tom Lane) (9.3)(9.2)(9.1)(9.0)</li>
<p>
readline ではなく libedit でビルドされた psql では、s コマンドによるヒストリ表示がおよそ読めないものでした。
</p>
<p>
そこで、このライブラリを用いるのではなく、自身でヒストリを表示する方式に修正されました。さらに良い副作用としてページャが使えるようになりました。
</p>
<p>
本修正で、libedit でコマンドヒストリを保存するとき、改行コードに一貫性がない場合における障害も修正されています。
</p>
<li>psql の watch コマンドで pset null で指定した null 表示を適用するようになりました。  (Fujii Masao) (9.3)</li>
<p>
これまでは設定が無視されていました。
</p>
<li>psql 拡張形式表示で border が 3 で、linestyle が ascii または unicode であるときに、一貫した表示になるように修正されました。  (Stephen Frost) (9.3)(9.2)(9.1)(9.0)</li>
<pre>
(修正前は以下のように末尾の罫線が不適切でした)
$ psql db1 &lt;&lt;'EOS'
&gt; pset border 3
&gt; pset linestyle ascii
&gt; x
&gt; SELECT * FROM t1 ;
&gt; EOS
[ RECORD 1 ]
| id | 1   |
| v  | AAA |
--+----
</pre>
<li>pg_dump でオブジェクトの依存関係を調べる処理が改善され、性能が向上しました。  (Tom Lane) (9.3)(9.2)(9.1)</li>
<p>
データベース内に、同一オブジェクト間に多重の依存性経路をもつケースが多くある場合に本修正の効果があらわれます。
</p>
<li>pg_dumpall が 8.1 以前のサーバをダンプできるように修正されました。  (Gilles Darold) (9.3)(9.2)</li>
<li>(pg_dump -s オプションによる) 定義のみのダンプを並行リストアするときに発生しうるデッドロックが修正されました。  (Robert Haas, Tom Lane) (9.3)(9.2)(9.1)(9.0)</li>
<li>カラムを一つも持たない複合型があるとき pg_dump --binary-upgrade がクラッシュしていたものが修正されました  (Rushabh Lathia) (9.3)(9.2)(9.1)(9.0)</li>
<p>
--binary-upgrade オプションは pg_upgrade コマンドから使用されます。
</p>
<li>pg_upgrade でデフォルトでないテーブルスペースのテーブルに対する fsyncに失敗していて、修正されました。  (Abhijit Menon-Sen, Andres Freund) (9.3)</li>
<p>
pg_upgrade 実行中に OS クラッシュ等が生じた場合にデータ欠損が生じる可能性がありました。
</p>
<li>pg_upgrade で新しいクラスタが TOAST を持たないテーブルに対して事前にTOAST テーブルを作成するときに適切に動作するように修正されました。  (Bruce Momjian) (9.3)</li>
<p>
これまでは OID 衝突によって失敗することがありました。
</p>
<li>pg_upgrade で autovacuum_multixact_freeze_max_age を古いクラスタに対して設定しないようになりました。  (Bruce Momjian) (9.3)</li>
<p>
本パラメータは 9.3.3 で追加されたため、9.3.2 までのサーバに対しては、失敗してしまいます。実際のところ設定する必要がないパラメータでした。
</p>
<li>pg_upgrade で、トランザクションID のエポック時間が保たれるように修正されました。  (Bruce Momjian) (9.3)</li>
<p>
この不具合は通常のPostgreSQLに影響するものではありませんが、Slony-I やlondiste などのレプリケーションツールに影響を与える可能性がありました。
</p>
<li>pg_receivexlog コマンドのメモリリークが修正されました。  (Fujii Masao) (9.3)</li>
<li>pg_receivexlog コマンドの verbose メッセージが意図せず抑制されており、修正されました。  (Fujii Masao) (9.3)</li>
<li>contrib/auto_explain が EXPLAIN ANALYZE 実行時に計画ノードごとの所用時間情報の出力に失敗することがあり、修正されました。  (Tom Lane) (9.3)(9.2)</li>
<li>contrib/citext のアップグレードスクリプトが修正されました。  (Tom Lane) (9.3)(9.2)(9.1)</li>
<li>contrib/hstore の hstore_to_json() 関数による整数オーバーフローと  (Heikki Linnakangas) (9.3)</li>
<p>バッファオーバーランを防ぐように修正されました。
</p>
<li>hstore_to_json_loose() 関数による数値の認識処理が修正されました。  (Andrew Dunstan) (9.3)</li>
<p>
これにより JSON の数値や文字列が正しく区別できるようになります。
</p>
<li>contrib/pageinspect の get_raw_page() 関数によるブロック数のチェックが修正されました。  (Tom Lane) (9.3)(9.2)(9.1)(9.0)</li>
<p>
間違ったロジックにより、リレーションの主フォークでないページへのアクセスが妨げられることがありました。
</p>
<li>contrib/pgcrypto の pgp_sym_decrypt() 関数で、メッセージ長がちょうど 2 の乗数から 6 を引いた長さである場合に失敗しており、修正されました。  (Marko Tiikkaja) (9.3)(9.2)(9.1)(9.0)</li>
<p>
メッセージ長が 65530 バイト (2^16 - 6) や、16378 バイト(2^14 - 6) などの場合に該当します。「Error:  Wrong key or corrupt data」が生じていました。なお、メッセージ長が (2^14 x N - 6) N=正整数 の場合に該当するケースも報告されています。
</p>
<li>contrib/pg_test_fsync によるファイルディスクリプタリークが修正されました。  (Jeff Janes) (9.3)(9.2)(9.1)</li>
<p>
これにより Windows の一時ファイルの削除に失敗することがありました。
</p>
<li>contrib/xml2 の xslt_process() 関数がクラッシュを回避するように修正されました。  (Mark Simonetti) (9.3)(9.2)(9.1)(9.0)</li>
<p>
これまでの保守的すぎる揮発性指定は、通常利用においては問題ありませんが、最適化と式インデックス利用の妨げとなっていました。本修正では拡張モジュールのバージョン番号は変更されません。
</p>
<li>contrib モジュールのデータ型追加のための入出力関数のいくつかに、適切な揮発性の指定が付加されました。  (Tom Lane) (9.3)(9.2)(9.1)</li>
<p>
これまでの保守的すぎる揮発性指定は、通常利用においては問題ありませんが、最適化と式インデックス利用の妨げとなっていました。本修正では拡張モジュールのバージョン番号は変更されません。
</p>
<li>バックグラウンドワーカープロセスの初期化について修正されました。  (Robert Haas) (9.3)</li>
<p>
Windowsプラットフォームで不具合の可能性がありました。
</p>
<li>ビルド時に互換性のない OpenLDAPバージョンを検知するようになりました。  (Noah Misch) (9.3)(9.2)(9.1)(9.0)</li>
<p>
OpenLDAP 2.4.24 から 2.4.31 は、PostgreSQL のバックエンドプロセスをクラッシュさせます。configure で警告を出すとともに、contrib/dblink の回帰テストにクラッシュを引き起こすシナリオを含めるようになりました。
</p>
<li>Visual C 以外での Windows むけビルドで、libpq.dll が確実に実行権限を付加してインストールされるように修正されました。   (Noah Misch) (9.3)(9.2)(9.1)(9.0)</li>
<li>UTCオフセットが変化するタイムゾーン略記法に対応しました。  (Tom Lane) (9.3)(9.2)(9.1)(9.0)</li>
<p>
与えられた日付に応じて、タイムゾーン略記法をその日付時点での正しい UTC オフセットに関連付ける動作をするようになります。
</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>
