<?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 10.3 &#8211; SRA OSS Tech Blog</title>
	<atom:link href="https://www.sraoss.co.jp/tech-blog/tag/postgresql-10-3/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>Wed, 04 Nov 2026 06:22:01 +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 10.3 &#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 10.4 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/10-4/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Tue, 15 May 2018 01:00:21 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 10]]></category>
		<category><![CDATA[PostgreSQL 10.3]]></category>
		<category><![CDATA[PostgreSQL 10.4]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=352</guid>

					<description><![CDATA[このリリースは 10.3 からの修正リリース(2018/5/10リリース)です。 10.x からのアップデートではダンプ、リストアは不要です。 また、10.3 より前のバージョンからアップデートを行う場合は 10.3 に ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 10.3 からの修正リリース(2018/5/10リリース)です。<br />
10.x からのアップデートではダンプ、リストアは不要です。</p>
<p>また、10.3 より前のバージョンからアップデートを行う場合は 10.3 に関する技術情報を参照してください。</p>
<p><span id="more-352"></span></p>
<h3 class="background">PostgreSQL 10.3 から 10.4 への変更点</h3>
<p>10.4、9.6.9、9.5.13、9.4.18、9.3.23 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<hr />
<ol>
<li>contrib/adminpack の pg_logfile_rotate() 関数から全ユーザに与えられていた実行権限が削除されました。 (Stephen Frost) (10)(9.6)</li>
<p>
adminpack がインストールされている場合、全てのユーザがログファイルのローテーションをリクエストすることができ、セキュリティ的な問題がありました。
</p>
<p>
今回のアップデートを適用後、運用管理者は「ALTER EXTENSION adminpack UPDATE;」を実行して adminpack を更新する必要があります。これは adminpack がインストールされているすべてのデータベースが対象となります。(CVE-2018-1115)
</p>
<li>いくつかの組み込み関数の誤った変動性区分の指定が修正されました。 (Thomas Munro, Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
以下の関数は VOLATILE とすべきでした。変動する操作を含むかもしれないユーザから与えられた問い合わせを実行するためです。そうなっていなかったためプラン作成での誤った最適化が行われる危険がありました。
</p>
<pre>
query_to_xml
cursor_to_xml
cursor_to_xmlschema
query_to_xmlschema
query_to_xml_and_xmlschema
</pre>
<p>
既存データベースクラスタの関数定義はバージョンアップしただけでは修正されません。使用している各データベースにおいて管理者ユーザにて以下の SQLを実行して、修正することができます。
</p>
<pre>
ALTER FUNCTION pg_catalog.query_to_xml(text, boolean, boolean, text) VOLATILE;
ALTER FUNCTION pg_catalog.cursor_to_xml(refcursor, int, boolean, boolean, text) VOLATILE;
ALTER FUNCTION pg_catalog.cursor_to_xmlschema(refcursor, boolean, boolean, text) VOLATILE;
ALTER FUNCTION pg_catalog.query_to_xmlschema(text, boolean, boolean, text) VOLATILE;
ALTER FUNCTION pg_catalog.query_to_xml_and_xmlschema(text, boolean, boolean, text) VOLATILE;
</pre>
<li>いくつかの組み込み関数で間違って parallel-safe とされていたものが修正されました。 (Thomas Munro, Tom Lane) (10)(9.6)</li>
<p>
以下の関数が該当します。
</p>
<pre>
brin_summarize_new_values
brin_summarize_range (10.x のみ)
brin_desummarize_range (10.x のみ)
gin_clean_pending_list
cursor_to_xml
cursor_to_xmlschema
ts_rewrite
ts_stat
binary_upgrade_create_empty_extension
pg_import_system_collations
</pre>
<p>
これらの関数は今まで parallel-restricted とされており予期せぬクエリエラーを発生させる可能性がありました。本修正は新規インストールの場合は問題ないですが、既にインストールされているものに関しては paralle-restricted のままになります。修正のためには、管理者ユーザで以下のように関数の pg_proc エントリを修正するか（全てのデータベースで実行する必要があります）、pg_upgrade を使用して本修正がされているバージョンに変更する必要があります。
</p>
<pre>
（brin_summarize_new_values 関数に対する補正 SQL 例：）
ALTER FUNCTION pg_catalog.brin_summarize_new_values(regclass) PARALLEL UNSAFE;
</pre>
<li>削除済みで未 VACUUM の TOAST エントリに一致する TOAST 値 OID の再利用を回避するようになりました。 (Pavan Deolasee) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
一度 OID カウンタが周回していると、同じ TOAST テーブルで以前に削除されたエントリと OID が一致する TOAST 値を割り当てる可能性があります。そのエントリが未だ VACUUM されていない場合、以下のエラーがもたらされ、これが削除済みエントリが VACUUM で除去されるまで持続します。
</p>
<pre>
ERROR: unexpected chunk number 0 (expected 1) for toast value nnnnn
</pre>
<p>
新たな TOAST エントリを作るときにそのような OID を選ばないように修正されました。
</p>
<li>パーティション化されたテーブルに COPY をするときに、構成要素の個々パーティション上で正しくあらゆる CHECK 制約を強制するようになりました。 (Etsuro Fujita) (10)</li>
<p>
これまではパーティション化されたテーブル全体にむけて宣言された制約のみが検査されていました。
</p>
<li>パーティションキー比較関数むけのメモリ管理が修正されました。 (&Aacute;lvaro Herrera, Amit Langote) (10)</li>
<p>
この誤りにより、パーティションキーにユーザ定義演算子クラスを使うときにクラッシュをひき起こす恐れがありました。
</p>
<li>パーティション化されたテーブル内の同一の行型を持たないいくつかの要素パーティションに問い合わせがタプルを挿入するときクラッシュする可能性があり、修正されました。 (Etsuro Fujita, Amit Langote) (10)</li>
<li>ANALYZE の pg_class.reltuples を更新するアルゴリズムが変更されました。 (David Gould) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
これまでは ANALYZE により実際にはスキャンされないページは、元のタプル密度を維持していると見做されていました。ANALYZE が全体の一部のみサンプリングする大きなテーブルでは、これは全体のタプル密度見積りが大幅に変化しないことを意味し、そのためテーブルの実際の変動にかかわらず、reltuples はテーブルの物理サイズ（relpages）におよそ比例する形で変化しました。これにより、事実上自動 VACUUM が遮断されるほど reltuples が実際より大きくなりすぎる動作がみられました。
</p>
<p>
ANALYZE で抽出したサンプルが統計的に偏りの無いものと仮定して、観測されたサンプルのタプル密度をテーブル全体に外挿推定するように、修正されました。
</p>
<li>拡張統計オブジェクトが、CREATE TABLE ... LIKE ... INCLUDING ALL で複製されたテーブルの属性に含まれるようになりました。 (David Rowley) (10)</li>
<p>
また、この個別制御をする INCLUDING STATISTICS オプションが追加されました。
</p>
<li>bigint型の IDENTITY列を伴う CREATE TABLE ... LIKE が修正されました。 (Peter Eisentraut) (10)</li>
<p>
long が 32 ビットのプラットフォーム（大部分の 32 ビットマシンのみならず 64ビット Windows が含まれます）では、コピーされたシーケンスパラメータが 32 ビットに切り捨てされていました。
</p>
<li>SERIALIZABLE または REPEATABLE READ トランザクション隔離レベルで同時実行する CREATE INDEX CONCURRENTLY コマンドでのデッドロックが回避されました。 (Tom Lane) (10)(9.6)(9.5)(9.4)</li>
<li>REFRESH MATERIALIZED VIEW CONCURRENTLY が遅く実行される可能性があり、修正されました。 (Thomas Munro) (10)(9.6)(9.5)(9.4)</li>
<li>参照されるカーソルが IndexOnlyScan 実行プランを使うときにUPDATE/DELETE ... WHERE CURRENT OF が失敗しないように修正されました。 (Yugo Nagata, Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
予期せぬエラー「ERROR: cannot extract system attribute from virtual tuple」が発生する例が報告されていました。
</p>
<li>パラメタ化されたパスにプッシュされたJOIN句の不正なプラン作成が修正されました。 (Andrew Gierth, Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
この間違いは、単純なフィルタ条件であるべきときに外部結合に対する結合フィルタ条件の誤まった分別が生じ、誤った結合結果をもたらしました。
</p>
<p>
以下の誤動作例が報告されました。
</p>
<pre>
db=# CREATE TABLE t AS SELECT 1 AS x, '{10,20}'::int[] AS ys;
db=# SELECT * FROM t
LEFT JOIN (VALUES (1, 10), (2, 20)) AS q1 (x, y) ON q1.x = t.x
LEFT JOIN unnest(ys) q2 (y) ON q2.y = q1.y;
x | ys | x | y | y
---+---------+---+----+----
1 | {10,20} | 1 | 10 | 10
1 | {10,20} | 2 | 20 |
(2 rows)
</pre>
<li>複合インデックスの列に同じテーブルの列が現れて、これらインデックス列の一部だけが列の値を返せる演算子クラスを使うときに、誤った IndexOnlyScan プランが生成される可能性があり、修正されました。 (Kyotaro Horiguchi) (10)(9.6)(9.5)</li>
<p>
以下のようなインデックスで該当します。
</p>
<pre>
CREATE INDEX ON text_tbl USING gist (text_col gist_trgm_ops, text_col);
CREATE INDEX ON inet_tbl USING gist (inet_col gist_inet_ops, inet_col inet_ops);
</pre>
<li>トップレベルに AND/OR 条件の NULL と証明可能な副句を持つ CHECK 制約の、誤った最適化が修正されました。 (Tom Lane, Dean Rasheed) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
例えば以下のように「制約による除外」の最適化で除外すべきでない子テーブルが除外されてしまうことがあり得ました。
</p>
<pre>
db=# CREATE TABLE cnullp (f1 int);
db=# CREATE TABLE cnullc (check (f1 = 1 OR f1 = null)) INHERITS (cnullp);
db=# INSERT INTO cnullc VALUES (1), (2), (null);
db1=# EXPLAIN SELECT * FROM cnullp ;
QUERY PLAN
----------------------------------------------------------------
Append (cost=0.00..35.50 rows=2551 width=4)
-&gt; Seq Scan on cnullp (cost=0.00..0.00 rows=1 width=4)
-&gt; Seq Scan on cnullc (cost=0.00..35.50 rows=2550 width=4)
(3 rows)

db1=# EXPLAIN SELECT * FROM cnullp WHERE f1 = 2;
QUERY PLAN
------------------------------------------------------------
Append (cost=0.00..0.00 rows=1 width=4)
-&gt; Seq Scan on cnullp (cost=0.00..0.00 rows=1 width=4)
Filter: (f1 = 2)
(3 rows)
</pre>
<li>問い合わせが複数 GROUPING SETS を持ち、それらのいずれもがソートによる実行プランがとれないときのプランナのクラッシュが防止されました。 (Andrew Gierth) (10)</li>
<pre>
(大小比較ができないのでソート不能な xid 型によるクラッシュをひき起こす SQL 例)
db=# CREATE TABLE t18 (id int, x1 xid, x2 xid);
db=# INSERT INTO t18 VALUES (1, '1', '1'), (2, '2', '2'), (3,'3','3');
db=# SELECT x1, x2, count(*) FROM t18 GROUP BY GROUPING SETS ((x1), (x2));
</pre>
<li>GROUPING SETS の一部の使用法において、エグゼキュータのメモリ二重解放によるクラッシュが修正されました。 (Peter Geoghegan) (10)(9.6)(9.5)</li>
<li>トリガ関数内における遷移テーブルを自己結合する問い合わせの誤実行が修正されました。 (Thomas Munro) (10)</li>
<p>
UNION で遷移テーブルへの SELECT を繋ぐ場合なども該当します。
</p>
<li>テーブル書き換えのイベントトリガ追加が、そのようなトリガを呼び出すかもしれないコマンドと同時に行われた場合のクラッシュが回避されました。 (&Aacute;lvaro Herrera, Andrew Gierth, Tom Lane) (10)(9.6)(9.5)</li>
<li>準備されたトランザクションのコミットをしているときに、問い合わせのキャンセルやセッション終了割り込みが起きた場合の障害が回避されました。 (Stas Kelvich) (10)(9.6)(9.5)(9.4)(9.3)</li>
<li>繰り返し実行されているハッシュ結合での問い合わせ処理の間のメモリリークが修正されました。 (Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)</li>
<li>ビジビリティマップのバッファピンでメモリのリークまたは二重解放の可能性があり、修正されました。 (Amit Kapila) (10)(9.6)</li>
<li>ページに全て可視であると偽性の印付けするのを回避しました。 (Dan Wood, Pavan Deolasee, &Aacute;lvaro Herrera) (10)(9.6)</li>
<p>
これは一部タプルがロックされている（しかし削除されていない）場合に起きる可能性がありました。問い合わせが未だ正しく実行中の間、VACUUM は通常そのようなページを無視します。これはタプルがずっと凍結されないという長期の影響を伴います。
</p>
<p>
最近のリリースでは、これによりエラー「ERROR: found multixact nnnnn from before relminmxid nnnnn」を出しました。
</p>
<li>heap_prepare_freeze_tuple の厳格すぎるサニティチェックが修正されました。 (&Aacute;lvaro Herrera) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
これは pg_upgrade で 9.2 以前のバージョンからアップグレードされたデータベースにて、誤った「ERROR: cannot freeze committed xmax ...」エラーをひき起こしました。
</p>
<li>C 言語で記述された更新前に実行される行トリガが OLD タプルを返すときのダングリングポインタ参照が防止されました。 (Rushabh Lathia) (10)(9.6)(9.5)(9.4)(9.3)</li>
<li>自動 VACUUM ワーカをスケジューリングする間のロックが軽減されました。 (Jeff Janes) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
これまでの振る舞いは多テーブルデータベースにおいて潜在的なワーカの同時実行性を大幅に削いでいました。
</p>
<li>pg_stat_activity のデータをローカルメモリにコピーするときに、クライアントホスト名（client_hostname）が確実にコピーされるようになりました。 (Edmund Horner) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
これまでは、ローカルとされるスナップショットが共有メモリへのポインタを含んでおり、いずれかの存在するセッションが切断された場合に client_hostname が予期せず変わることがあり得ました。
</p>
<li>補助プロセスに対する pg_stat_activity の情報を正しく扱うようになりました。 (Edmund Horner) (10)</li>
<p>
各種補助プロセス（autovacuum launcher や background writer など）に対する application_name、client_hostname、query 属性が正しくないデータを見せる可能性がありました。
</p>
<li>ispell 辞書で不正な複合接辞の処理が修正されました。 (Arthur Zakirov) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
未初期化メモリアクセスが生じていました。
</p>
<li>テキスト列に対する SP-GiST インデックスで照合を伴う検索（不等演算子を使うインデックススキャン）が修正されました。 (Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
C ロケール以外の場合に該当する検索では誤った行が選択されました。マルチバイト文字でも影響があります。
</p>
<pre>
（報告された例）
db=# CREATE TABLE t32 (a text collate "cs_CZ");
db=# INSERT INTO t32 VALUES ('c'), ('ch'); -- チェコ語では ch で１文字
db=# SELECT * FROM t32 where a &lt; 'd';
a
----
c
(1 row)

db=# CREATE INDEX ON t32 USING spgist (a);
db=# SET enable_seqscan TO off;
db=# SELECT * FROM t32 where a &lt; 'd';
a
----
c
ch
(2 rows)
</pre>
<li>探索値(traversalValue)を使う SP-GiST 演算子クラスでの問い合わせの間のメモリリークが防止されました。 (Anton Dign&ouml;s) (10)(9.6)</li>
<li>SP-GiST インデックスの初期構築時に、インデックスタプルの数を正しく数えるようになりました。 (Tomas Vondra) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
これまで、タプル数はインデックス対象のテーブルと同じと報告されていましたが、これは部分インデックスの場合には誤りでした。
</p>
<li>GiST インデックスの VACUUM 中にインデックスタプル数を正しく数えるようになりました。 (Andrey Borodin) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
これまではヒープタプルの見積数を返していました。それは単なる推測であり、間違っている場合もありましたし、インデックスが部分的なものである場合は必ず間違っていました。
</p>
<li>ストリーミングレプリケーションのスタンバイが継続している WAL レコード内で滞ってしまった場合の動作が修正されました。 (Kyotaro Horiguchi) (10)(9.6)(9.5)(9.4)</li>
<p>
今までは XLogPageRead() が既に読み込みを終えた部分であったとしても、WAL の最初からストリーミングレプリケーションを再開していました。これにより稀にストリーミングレプリケーションが止まってしまう現象が生じました。
</p>
<li>walsender が再起動した際に、WAL データを二重に処理してしまう可能性が排除されました。 (Craig Ringer) (10)(9.6)(9.5)(9.4)</li>
<p>
walsender が $PGDATA/pg_replslot 内にデータを残した状態で終了してしまった場合、次の walsender がそこに残ったデータを捨てることなく開始して、データが重複する可能性がありました。
</p>
<li>ロジカルレプリケーションにおいて、型の OID がローカルとリモートで一致すると仮定しないように修正されました。 (Masahiko Sawada) (10)</li>
<p>
リモートのものをローカルのものとして使用しており、「ERROR: cache lookup failed for type XYZ」エラー、もしくはランダムに意図していないものが選択される可能性がありました。
</p>
<li>scalarltsel と scalargtsel が組み込みデータ型以外の型も受け付けるようになりました。 (Tomas Vondra) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
ユーザ定義の数値データ型で予期せぬ「ERROR: unsupported type: nnnnn」が生じることが報告されました。
</p>
<li>大量のクエリ結果が収集された後にサーバエラーが報告された時のlibpq が消費するメモリ量が削減されました。 (Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
エラーメッセージをパース後にクエリ結果を捨てていましたが、事前に捨てるようになりました。その結果メモリ消費量を抑え out-of-memory になる危険性が軽減されました。
</p>
<li>ecpg 内の連続した free() によるクラッシュが修正されました。 (Patrick Krecker, Jeevan Ladhe) (10)(9.6)(9.5)(9.4)(9.3)</li>
<li>MSVC を使用したビルドにて ecpg が long long int 変数を扱えるように修正されました。 (Michael Meskes, Andrew Gierth) (10)(9.6)(9.5)(9.4)(9.3)</li>
<li>ダンプ内でリストを値とする GUC 変数に対する間違ったクォーテーションが修正されました。 (Michael Paquier, Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
pg_dump の結果で local_preload_libraries、session_preload_libraries、shared_preload_libraries と temp_tablespaces 変数に対するクォーテーションの付け方が間違っていました。もしもこれらの設定が CREATE FUNCTION ... SET や ALTER DATABASE/ROLE ... SET にある場合に問題になる可能性がありました。
</p>
<li>pg_recvlogicalが v10より前のPostgreSQLに対して失敗しないように修正されました。 (Michael Paquier) (10)(9.6)(9.5)(9.4)</li>
<p>
前回のリリースにて変更された search_path へのプロテクトが追加されていましたが、10 より前のバージョンではレプリケーション接続で SQL を受け付けないため有効でなく、構文エラーが発生する可能性がありました。
</p>
<li>pg_rewind 起動中にソースサーバで削除されたファイルがターゲットサーバでも確実に削除されるようになりました。 (Takayuki Tsunakawa) (10)(9.6)(9.5)</li>
<p>
失敗していた場合、ターゲットサーバがデータ不整合に陥っていました。
</p>
<li>pg_rewind がデフォルト以外のテーブルスペースにあるテーブルデータを正しく扱えるように修正されました。 (Takayuki Tsunakawa) (10)(9.6)(9.5)</li>
<li>PL/pgSQL 整数 FOR ループのオーバーフロー処理が修正されました。 (Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
以前のコードではいくつかの GCC 以外のコンパイラではオーバーフローが検知されず、無限ループに陥っていました。
</p>
<li>PL/Python のリグレッションテストが Python 3.7 の環境でも成功するように調整されました。 (Peter Eisentraut) (10)(9.6)(9.5)(9.4)(9.3)</li>
<li>MSVC ビルドにて PL/Python と関連モジュールのリグレッションテストが Python 3 でもサポートされました。 (Andrew Dunstan) (10)(9.6)(9.5)(9.4)(9.3)</li>
<li>contrib/bloom インデックスの初期ビルドでのエラーが修正されました。 (Tomas Vondra, Tom Lane) (10)(9.6)</li>
<p>
インデックス内のタプル数を推測でなく確実にカウントすることで最後のタプルが取りこぼされる可能性がなくなりました。
</p>
<li>b64_encode と b64_decode 内部関数の名前が Solaris 11.4 の組み込み関数名と被らないように変更されました。 (Rainer Orth) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
b64_encode は pg_base64_encode に、b64_decode は pg_base64_decode に名前変更されました。
</p>
<li>タイムゾーンライブラリが IANA の tzcode release 2018e と同期されました。 (Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
これは zic タイムゾーンデータコンパイラが負の夏時間オフセットで動作するように修正します。PostgreSQL はこのようなタイムゾーンデータに直ちには対応しませんが、zic を IANA から直接取得したタイムゾーンデータで使う可能性がありますので、確実を期してアップデートされました。
</p>
<li>タイムゾーンデータファイルが tzdata release 2018d に更新されました。 (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
パレスチナと南極（ケーシー基地）の DST 法の変更、ポルトガルとその植民地、エンダーベリー島、ジャマイカ、タークス・カイコス諸島、ウルグアイの歴史的修正が加えられています。
</p>
<li>Microsoft Visual Studio 2015 でのビルドがサポートされました。 (Michael Paquier) (9.5)</li>
<p>
以前のリリースでも修正が行われていましたが、修正もれがありました。
</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 10.3 に関する技術情報</title>
		<link>https://www.sraoss.co.jp/tech-blog/pgsql/10-3/</link>
		
		<dc:creator><![CDATA[PostgreSQL技術グループ]]></dc:creator>
		<pubDate>Thu, 08 Mar 2018 08:33:36 +0000</pubDate>
				<category><![CDATA[PostgreSQL]]></category>
		<category><![CDATA[PostgreSQL 10]]></category>
		<category><![CDATA[PostgreSQL 10.2]]></category>
		<category><![CDATA[PostgreSQL 10.3]]></category>
		<category><![CDATA[アップデート]]></category>
		<guid isPermaLink="false">https://www.sraoss.co.jp/tech-blog/?p=356</guid>

					<description><![CDATA[このリリースは 10.2 からの修正リリース(2018/3/1リリース)です。 10.x からのアップデートではダンプ、リストアは不要です。 しかしながら、下記 1 番、2 番の項目を確認して、必要に応じて対応を行うこと ...]]></description>
										<content:encoded><![CDATA[<p>このリリースは 10.2 からの修正リリース(2018/3/1リリース)です。<br />
10.x からのアップデートではダンプ、リストアは不要です。<br />
しかしながら、下記 1 番、2 番の項目を確認して、必要に応じて対応を行うことを推奨します。<br />
また、10.2 よりも前のバージョンからアップデートする場合には、<a href="/tech-blog/pgsql/10-2/ ">10.2 のリリース情報</a>も参照してください。</p>
<p><span id="more-356"></span></p>
<h3 class="background">PostgreSQL 10.2 から 10.3 への変更点</h3>
<p>10.3、9.6.8、9.5.12、9.4.17、9.3.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。</p>
<hr />
<ol>
<li>他ユーザからの search_path を使った「トロイの木馬」攻撃を防御する PostgreSQL とアプリケーションの設定方法がドキュメントに記載されました。 (Noah Misch) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
害意あるユーザから書き込み可能なスキーマを含む search_path 設定を使うことは、そのユーザが問い合わせの制御を取ること、そして、攻撃されたユーザの権限で任意の SQL コードを実行することをきわめて容易に可能にします。
</p>
<p>
そのため、search_path に信用できないスキーマを含めないようにすることが推奨されます。ドキュメントのスキーマ、libpq、拡張および CREATE FUNCTION の各ページについて記載を改定しました。
</p>
<p>
特に public スキーマはデフォルトで存在し、デフォルトで search_path に含まれており、全てのユーザでスキーマ上でオブジェクト作成が可能となっています。同じデータベースにアクセスする信用できない（本来制限されている）ユーザがいて、それでいて public スキーマと search_path 設定がデフォルト状態のままである場合には明らかに本脆弱性に該当します。(CVE-2018-1058)
</p>
<li>pg_dump や他のクライアントプログラムで安全でない search_path 設定の使用が回避されました。 (Noah Misch, Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
pg_dump、pg_upgrade、vacuumdb、およびその他各種の PostgreSQLで提供されるクライアントプログラム自体に前項で記載した類のハイジャックに対する脆弱性がありました。これらプログラムはたいてい管理者ユーザで実行されるので狙われやすいターゲットです。これらを安全にするため、動作時の search_path 設定に pg_catalog スキーマだけ含まれるようになりました。また、autovacuum worker も同様に動作するようになりました。なお、pgbench と psql は本修正の対象外です。
</p>
<p>
これは非互換箇所のある修正です。これらのプログラムから間接的に実行されるユーザ定義関数（例えばインデックス式の関数）が search_path 設定に依存して記述されている（例えば public スキーマ下の関数をスキーマ修飾無しに参照している）場合、エラーが生じるようになります。(CVE-2018-1058)
</p>
<li>ロジカルレプリケーションで伝播不可能なリレーションに対して伝播しようとするのを防ぐようになりました。 (Peter Eisentraut) (10)</li>
<p>
FOR ALL TABLES と指定されたパブリケーションが誤ってマテリアライズドビューや information_schema テーブルの変更を伝播していました。これらは変更ストリームから無視されるべきものです。
</p>
<li>サブプラン内の CTE 参照で同時更新再チェック動作の間違いが修正されました。 (Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
CTE（WITH 句参照）が InitPlan や SubPlan で使われていて、問い合わせが同時更新された行に更新やロックをするために再チェックを必要とする場合に、誤った結果が返ることがありました。
</p>
<li>外部結合でマージ結合句が重複した場合にプランナが失敗する問題が修正されました。 (Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
コードの誤りにより稀なケースで「ERROR: left and right pathkeys do not match in mergejoin」や「ERROR: outer pathkeys do not match mergeclauses planner」といったエラーが生じていました。
</p>
<pre>
（10.2 でのエラーが発生する SQL を実行）
test=# EXPLAIN (COSTS off)
SELECT * FROM j1 FULL OUTER JOIN
(SELECT * FROM j2 ORDER BY j2.id DESC, j2.num asc) j2
ON j1.id = j2.id AND j1.id = j2.num;
ERROR: left and right pathkeys do not match in mergejoin

（10.3 での応答）
QUERY PLAN
------------------------------------------------------
Merge Full Join
Merge Cond: ((j2.id = j1.id) AND (j2.num = j1.id))
-&gt; Sort
Sort Key: j2.id DESC, j2.num
-&gt; Seq Scan on j2
-&gt; Sort
Sort Key: j1.id DESC
-&gt; Seq Scan on j1
(8 rows)
</pre>
<li>pg_upgrade でマテリアライズドビューのための relfrozenxid の保存に失敗する問題が修正されました。 (Tom Lane, Andres Freund) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
アップグレード後にマテリアライズドビューのデータが破損する可能性がありました。「ERROR: could not access status of transaction ...」や「ERROR: found xmin ... from before relfrozenxid ...」というエラーが現れます。
</p>
<p>
この問題は、めったに更新されない、もしくは REFRESH MATERIALIZED VIEW CONCURRENTLY のみで更新をしていたマテリアライズドビューで発生しやすいものと見られます。
</p>
<li>pg_dump の出力の誤りが修正されました。 (Alexey Bashtanov) (10)</li>
<p>
シーケンスの MAXVALUE や MINVALUE がデフォルト値であるなら、ダンプ出力で省略しますが、その判断が間違っていました。
</p>
<p>
大きな値を指定した場合に以下のような誤動作が報告されました。
</p>
<pre>
（誤動作例）
db=# CREATE SEQUENCE foo INCREMENT BY -1
MINVALUE -9223372036854775808 MAXVALUE 9223372036854775807;
db=# q
$ pg_dump db
: 中略
CREATE SEQUENCE foo
START WITH 9223372036854775807
INCREMENT BY -1
NO MINVALUE
NO MAXVALUE
CACHE 1;
: 後略
</pre>
<li>pg_dump の STATISTICS オブジェクトに対する扱いが修正されました。 (Tom Lane) (10)</li>
<p>
拡張統計のオブジェクトが正しいスキーマにリストアされなかったり所有者が正しくない状態になる可能性がありました。
</p>
<li>エラーコンテキストスタックで間違った PL/Python の関数名が報告されていた問題が修正されました。 (Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)</li>
<p>
以下のように入れ子で PL/Python を呼び出している場合において該当します。
</p>
<pre>
(障害がおきる例)
db=# CREATE FUNCTION notice_innerfunc() RETURNS int AS $$
plpy.execute("DO LANGUAGE plpythonu $x$ plpy.notice('inside DO') $x$")
return 1
$$ LANGUAGE plpythonu;

db=# CREATE FUNCTION notice_outerfunc() RETURNS int AS $$
plpy.execute("SELECT notice_innerfunc()")
return 1
$$ LANGUAGE plpythonu;
</pre>
<p>
また、入れ子になった PL/Python の DO ブロックは一部のプラットフォームで NULL ポインタ参照によるクラッシュをひき起こす可能性がありました。
</p>
<li>contrib/auto_explain の log_min_duration の最大値が約 35 分から、およそ 24 日間までに引き伸ばされました。 (Tom Lane) (10)(9.6)(9.5)(9.4)(9.3)</li>
<li>拡張モジュールを Windows に容易に移植できるようにするために、関連する GUC 変数が PGDLLIMPORT としてマークされました。 (Metin Doslu) (10)(9.6)</li>
</ol>

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

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