このリリースは 9.2.3 からの修正リリース(2013/4/4リリース)です。
9.2.x からのアップデートではダンプ、リストアは不要です。
本リリースでは GiST インデックス管理のエラーがいくつか修正されています。
本アップデートのインストール後は、後述する条件に合致する GiST インデックスの REINDEX が推奨されます。
また、9.2.2 より前のバージョンからアップデートを行う場合は 9.2.2 に関する技術情報を参照してください。
このリリースは 9.2.3 からの修正リリース(2013/4/4リリース)です。
9.2.x からのアップデートではダンプ、リストアは不要です。
本リリースでは GiST インデックス管理のエラーがいくつか修正されています。
本アップデートのインストール後は、後述する条件に合致する GiST インデックスの REINDEX が推奨されます。
また、9.2.2 より前のバージョンからアップデートを行う場合は 9.2.2 に関する技術情報を参照してください。
このリリースは 9.2.2 からの修正リリース(2013/2/7リリース)です。
9.2.x からのアップデートではダンプ、リストアは不要です。
また、9.2.2 より前のバージョンからアップデートを行う場合は 9.2.2 に関する技術情報を参照してください。
このリリースは 9.2.1 からの修正リリース(2012/12/6リリース)です。
9.2.x からのアップデートではダンプ、リストアは不要です。
ただし、下記の最初修正項目に記述されている通り、CONCURRENTLY で作成されたインデックスの問題を修正するために REINDEX が必要な場合があります。
また、9.2.0 からアップデートを行う場合は 9.2.1 に関する技術情報を参照してください。
このリリースは 9.2.0 からの修正リリース(2012/9/24リリース)です。
9.2.x からのアップデートではダンプ、リストアは不要です。
ただし、データ破損の不具合の影響から復旧させるために、REINDEX 及び VACUUM を実行することが推奨されます。
このページでは PostgreSQL 9.2 (2012/9/10リリース)に関する技術情報をお届けします。
本ドキュメントは PostgreSQL のリリースノートをもとに弊社で解説を加えたものです。
本メジャーバージョンアップの主な機能追加と性能改善は以下のとおりです。
上述の項目を含めて、以下のセクションで変更点をより詳しく説明します。
全ての以前のリリースからデータの移行を行うためには、pg_dumpを使用したダンプ/リストア、または、pg_upgrade の使用が必要です。 バージョン9.2には、以前のリリースとの互換性に影響を与える変更がいくつか含まれます。以下の非互換性に注意してください。
spclocation にはテーブルスペースのディレクトリパスが格納されますが、データベースクラスタの pg_tblspc 以下にシンボリックリンクがあるため、重複するデータ項目でした。
本修正によりサーバが停止してる間にテーブルスペースディレクトリの移動が可能になります。
また、テーブルスペースの OID からディレクトリパスを返す pg_tablespace_location() 関数が追加されました。
以前に most_common_valsカラム、most_common_freqsカラムに在ったデータは、most_common_elemsカラム、most_common_elem_freqsカラムから参照できます。
代わりに hstore(text, text) 関数を使う必要があります。
「=>」という演算子をユーザ定義する際には、SQL標準で予約されているトークンを別目的で使おうとしているということで、PostgreSQL 9.0 から、警告メッセージが吐かれていました。
これが行われない場合、不正な XML が出力されることがありえました。
実行例
=# select xpath('//text()', '<root>&lt;</root>');
xpath -------- {&lt;} (1 row)
xpath ------- {<} (1 row)
並行して DROP操作が行なわれている直後に実行して、これら関数を呼び出すクエリがエラーを返すことを防ぎます。
UTC に依存した計算は矛盾していました。
以前の振る舞いも、値を “timestamp with time zone” 型にキャストすることで可能です。
以下のような SQL の実行結果が 9.2 バージョンとそれ以前とで異なることとなります。
=# select EXTRACT (EPOCH FROM '2012-09-01 00:00:00'::timestamp); date_part ------------ 1346457600 (1 row)
以前は SELECT ’04:00:00 yesterday’::timestamp で昨日の真夜中(0時)の時刻を返していました。
(以前の不適切な動作例)
=# SELECT now(); now ------------------------------- 2012-09-06 14:00:14.021352+09 (1 row) =# select '04:00:00 yesterday'::timestamp; timestamp --------------------- 2012-09-05 00:00:00 (1 row)
以前は 4桁未満の年やマスクが与えられた時に一貫性が欠けていました。
以下のような SQL の実行結果が 9.2 バージョンとそれ以前とで異なることとなります。
(9.1.5 の実行結果、9.2 バージョンなら 1999年と解釈される) =# SELECT to_date('31 12 99', 'DD MM YY'); to_date ------------ 2099-12-31 (1 row)
以前は非ドメイン型に対する所有者とスキーマの変更が可能になっていました。
クオートされていない言語識別子は、まだ小文字化されますが、クオートされた文字列は強制的な小文字化を行ないません。
そのため例えば CREATE FUNCTION … LANGUAGE ‘C’ はもはや動作しません。
‘c’ と記述しなければならないか、あるいはクオートを省略するのが良いです。
この変更により、自己参照外部キー制約における正しいトリガ発火順序が、特異なケースでも担保されます。
以前まで、これらの使用は、空白文字列で分離された時だけ正しく展開されました。
=# echo 'FOO'BAR FOO BAR
=# echo 'FOO'BAR FOOBAR
ダブルクオートされた振舞を実現するには、ユーザがコマンド引数でダブルクオートを指定する必要があります。
ダブルクオートを指定する例
$ clusterdb -t "Tbl01" dbname
以前の createuser は、色々なユーザ設定に関連したプロンプトを出しました。
–interactive を指定すると以前の振る舞いをします。
これまでハードコードされていた server.crt、server.key、root.crt、root.ctl ファイルの配置を変更することができます。
もはや CA(crt) と CRL ファイルはデフォルトの名前を持ちません。これらを指定した場合、そのファイルは存在しなければなりません。
この動作は既に “pg_ctl -l postmaster.log” で行なうことができます。
wal senderプロセスが休止をやめて動作を再開すべきケースを検知できるようになったため、固定の休止時間を指定する必要がなくなりました。
もともとこの設定によって提供される検査は疑わしいものでした。
任意の設定に任意のクラス名をプレフィックス指定することができます。
その他のシステムテーブルと揃えるための変更となります。
state には「active」「idle」「idle in transaction」など状態が表示され、state_change には state が変った時刻が記録されます。
これまでは current_query カラムに状態情報も表示していました。
以下のビューのカラムが該当します。
pg_stat_user_functions.total_time pg_stat_user_functions.self_time pg_stat_xact_user_functions.total_time pg_stat_xact_user_functions.self_time
ヒープとはテーブルのデータ本体が格納されている領域のことです。
この機能はよく「index only scan」と呼ばれます。
以下のようにインデックス上のカラムだけを参照する問い合わせに Index Only Scan プランタイプが使われます。
=# EXPLAIN SELECT aid FROM pgbench_accounts; QUERY PLAN ---------------------------------------------------------------- Index Only Scan using pgbench_accounts_pkey on pgbench_accounts (cost=0.00..12996.80 rows=500000 width=4)
Index Only Scan が使えるのはヒープページの内、投入時点または前回 VACUUM時点以降に変更されたデータが無い箇所です。したがって、本機能が効果的なのは、書き込みの少ないテーブルといえます。
本機能の実現のためビジビリティマップがクラッシュセーフになりました。
SP-GiST は GiST のように柔軟ですが、不均衡に分割された検索構造をサポートします。
SP-GiST に向いた問題むけには、インデックス構築速度、検索速度とも GiST に優ります。
これまで、同時多数のコミットは書き込み処理で内部ロック競合を招き効率的ではありませんでした。
これにより Windows のセッションでより多くのファイルを開いて使えます。
以前は、バックグラウンドライタープロセスが、ダーティページの書き込みとチェックポイントの両方を行なっていました。これらの処理を二つのプロセスに分離させることで、それぞれの目標をより予測通りに完了させることができます。
これまでは wal_writer_delay だけが WAL をディスクへフラッシュさせるきっかけになっていました。今は WAL バッファが一杯になることも WAL 書き込みのきっかけになります。
これらの変更により、何も行なうことがない時に、プロセスが起きる頻度を減らし、待機サーバの消費電力を劇的に減らします。
これまでプリペアドステートメントは全てのパラメータ値に対して常に単一の汎用プランが使われました。このことで定数を直接記載した非プリペアドステートメントのプランより劣ることがよくありました。
カスタムプランに効果がない場合が繰り返されたときには、汎用プランが使われるようになります。本修正はプリペアドステートメント利用の性能ペナルティを取り除きます。PL/pgSQL内のダイナミックステートメントを除くSQL実行もこの恩恵をうけます。
以下のように一つのプリペアドステートメントに対して、パラメータによってプランタイプが変化します。
=> PREPARE p1 (bigint) AS SELECT * FROM pgbench_accounts WHERE aid < $1; => EXPLAIN (COSTS OFF) EXECUTE p1(100000); QUERY PLAN ---------------------------------- Seq Scan on pgbench_accounts Filter: (aid < 100000::bigint) => EXPLAIN (COSTS OFF) EXECUTE p1(10); QUERY PLAN ---------------------------------------------------- Index Scan using pgbench_accounts_pkey on pgbench_accounts Index Cond: (aid < 10::bigint)
新たに導入されたパラメータ化パス機構では、内側のインデックススキャンで一段(あるいは多段)上位の結合におけるリレーションの値を使うことができます。このことは、外部結合など、意味論的に許される結合順序が制限される場合に性能を大きく改善できます。
以下にプラン差異の例を示します。t1、t2、t3 はいずれも unique1、unique2、hundred カラムにインデックスを持つ 10万行のテーブルです。9.2 の場合にはt2 と t3 の結合に t1 の値に基づく条件フィルターが適用されています。
=# EXPLAIN SELECT * FROM t1 LEFT JOIN (t2 JOIN t3 ON t2.thousand = t3.unique2) ON t1.hundred = t2.hundred AND t1.ten = t3.ten WHERE t1.unique1 = 1;
QUERY PLAN --------------------------------------------------------------------------------- Nested Loop Left Join (cost=5.04..277.78 rows=10 width=732) -> Index Scan using t1_u1 on t1 (cost=0.00..8.28 rows=1 width=244) Index Cond: (unique1 = 1) -> Nested Loop (cost=5.04..269.40 rows=10 width=488) Join Filter: (t1.ten = t3.ten) -> Bitmap Heap Scan on t2 (cost=5.04..224.95 rows=100 width=244) Recheck Cond: (t1.hundred = hundred) -> Bitmap Index Scan on t2_h (cost=0.00..5.01 rows=100 width=0) Index Cond: (t1.hundred = hundred) -> Index Scan using t3_u2 on t3 (cost=0.00..0.43 rows=1 width=244) Index Cond: (unique2 = t2.thousand) (11 rows)
QUERY PLAN ------------------------------------------------------------------------------ Hash Right Join (cost=911.28..2580.38 rows=10 width=732) Hash Cond: ((t2.hundred = t1.hundred) AND (t3.ten = t1.ten)) -> Hash Join (cost=903.00..2497.00 rows=10000 width=488) Hash Cond: (t2.thousand = t3.unique2) -> Seq Scan on t2 (cost=0.00..445.00 rows=10000 width=244) -> Hash (cost=445.00..445.00 rows=10000 width=244) -> Seq Scan on t3 (cost=0.00..445.00 rows=10000 width=244) -> Hash (cost=8.27..8.27 rows=1 width=244) -> Index Scan using t1_u1 on t1 (cost=0.00..8.27 rows=1 width=244) Index Cond: (unique1 = 1) (10 rows)
ラッパーは外部テーブルに対する複数のアクセスパスを提供できるようになり、より柔軟な結合プランの生成が可能となりました。
constraint_exclusion = on であるときに限った実装となります。
(9.2 での実行例)
=# EXPLAIN SELECT unique1 FROM t1 WHERE unique1 = ANY(ARRAY[7164, 1314, 5222]); QUERY PLAN ---------------------------------------------------------------------- Index Only Scan using t1_u1 on t1 (cost=0.00..24.82 rows=3 width=4) Index Cond: (unique1 = ANY ('{7164,1314,5222}'::integer[])) (2 rows)
boolean型に対する min/max関数は用意されていませんが、bool_and関数、bool_or関数でインデックスが使われるようになります。
これまでは常に1行しか返らない扱いとなっていました。
=# EXPLAIN SELECT generate_series(1, 100) ; QUERY PLAN ------------------------------------------ Result (cost=0.00..0.01 rows=1 width=0) (1 row)
=# EXPLAIN SELECT generate_series(1, 100) ; QUERY PLAN --------------------------------------------- Result (cost=0.00..5.01 rows=1000 width=0) (1 row)
これは配列に対する <@、&&、@> 演算子(包含と重なり)の選択率予測を改善します。
これまでは管理者ユーザは暗黙的にすべてのロールのメンバーとして扱われていました。
以下のように pg_hba.conf を記述したとして、
local testdb +group1 trust local testdb all reject
PostgreSQL 9.1.x では、group1 のメンバーと定義していなくとも管理者ユーザ(postgres) は、接続できてしまいました。9.2 であれば、以下のようなエラーとなります。これは非互換の仕様変更となります。
$ psql -U postgres -d testdb psql: FATAL: pg_hba.conf rejects connection for host "[local]", user "postgres", database "testdb"
以下のようなログが出て、PostgreSQL起動にも失敗するようになります。
LOG: configuration file "/data/9.2/pg_hba.conf" contains no entries FATAL: could not load pg_hba.conf
reload した場合には、以下警告が出て、以前の pg_hba.conf 設定のままになります。
WARNING: pg_hba.conf not reloaded
log_autovacuum_min_duration 設定によって書かれるログが以下のようになります。
LOG: automatic vacuum of table "postgres.public.t1": index scans: 1 pages: 0 removed, 9 remain tuples: 500 removed, 500 remain buffer usage: 66 hits, 4 misses, 5 dirtied avg read rate: 14.902 MiB/s, avg write rate: 18.628 MiB/s system usage: CPU 0.00s/0.00u sec elapsed 0.00 sec
これまでは、サーバがマスターモードになるときに一度だけ失敗が報告されるというケースがありました。
複数のPostgreSQLインスタンスのログを区別する用途で利用できます。postgresql.conf の event_source設定で指定します。
デッドロック発生回数が記録されます。
SET文、SET LOCAL文による指定が可能となり、デッドロックの可能性のあるトランザクションだけ短いタイムアウトを指定するといった使い方が可能となります。以前は、設定ファイルを変更して reload が必要でした。
管理者ユーザが SETを行ったかどうかは、システムで記憶されます。
これにより、pg_ctl の PGDATA や -D オプションで設定のみのディレクトリを指定する場合の取扱いが改善されました。以下のように使用します。
$ postmaster -C shared_buffers 4096 $ postmaster -C archive_mode off
これにより、pg_database.datcollate もしくは pg_database.datctype がサーバ再起動時に異なる解釈をされることを防ぎます。
これまで、COLLATE と CTYPE に空文字列を指定すると、警告が出るけれど空文字列のまま設定されました。
これまでは、特定セッションで無効の設定がある場合、全ての設定の変更がそのセッションのために無視される原因となっていました。
これは、設定ファイルが存在しない場合でもエラーを発生させないことを除いて、include と同じ振る舞いをします。
これによりサーバ起動時に処理コストを要するタイムゾーン調査をしなくて済みます。
これまでは、マスターサーバのみがストリーミングレプリケーションのログファイルをスタンバイサーバに送信できていました。
本変更はよく、カスケードレプリケーションに対応した、という言い方をされます。
このモードでは、スタンバイサーバが自身の OS にトランザクションデータを書き込むのを待つように指定できます。ただし、スタンバイサーバのディスクにデータがフラッシュされるまで待つわけではありません。
アーカイブWALファイルをリモートの PostgreSQLサーバから取得する専用ツールです。WALファイルの完成を待たず、更新が発生するたびにデータ取得し、変更を書き込みます。
これにより、プライマリサーバが WAL ファイルを破棄する前に、スタンバイサーバへ WAL ファイルを渡すことができます。
クライアント接続に対する write() システムコールに失敗した場合に接続が切れたと判断します。
行の値を hstore型や JSON型に変換するときにカラム名を利用することができます。
これまでは、?column? が用いられていました。
=# SELECT (SELECT id FROM t1 ) ; id ---- 1
?column? ---------- 1
不明な定数は演算子のもう一方と同じ型であるとするという以前からの推定方法が、単純な演算子の一致のみならず、多相演算子を考慮したときにも適用されるようになりました。
これらキャストは無効です。
これによって、大量の行に insert や update を実行しているときに、問題のある列を発見しやすくなりました。
ロックを追加して多くのケースで「ERROR: cache lookup failed for ...」というエラーが生じないようになりました。
また、スキーマにテーブル等を追加する操作と、スキーマから削除する操作が同時に実行できなくなります。これはシステムカタログの不整合を引き起こしていました。
これにより他のセッションをブロックせずにインデックスを削除できます。
自動で改行が入るようになります。
NOT VALID を指定した CHECK 制約は、既存の行については制約を満たしているか検査しません。INSERT や UPDATE をしたときには検査されます。ALTER TABLE VALIDATE 文で既存の行について検査させることもできます。
以下に実行例を示します。
=# ALTER TABLE t1 ADD CHECK (id > 1) NOT VALID; ALTER TABLE =# SELECT * FROM t1 WHERE id = 1; id | v ----+---------------------------------- 1 | c4ca4238a0b923820dcc509a6f75849b (1 row) =# ALTER TABLE t1 VALIDATE CONSTRAINT t1_id_check; ERROR: check constraint "t1_id_check" is violated by some row =# update t1 set v = 'a' WHERE id = 1; ERROR: new row for relation "t1" violates check constraint "t1_id_check" DETAIL: Failing row contains (1, a).
この制約は親テーブルのみに有効で、子テーブルには適用されません。
テーブル変更のうち、以下の処理ではテーブル作り直しが不要となります。
以前は以下のように変更にともなって、テーブルが作り直され、格納されるファイルが変更されていました(relfilenode が変わることでわかります)。
=# CREATE TABLE t1 (id int primary key, v varchar(10)); CREATE TABLE =# SELECT oid, relname, relfilenode FROM pg_class WHERE relname = 't1'; oid | relname | relfilenode -------+---------+------------- 37177 | t1 | 37177 (1 row) # ALTER TABLE t1 ALTER v TYPE varchar(11); ALTER TABLE =# SELECT oid, relname, relfilenode FROM pg_class WHERE relname = 't1'; oid | relname | relfilenode -------+---------+------------- 37177 | t1 | 37182 (1 row)
たとえば、ALTER FOREIGN TABLE IF EXISTS foo RENAME TO bar などに追加されています。
なお、もともと ALTER TYPE文を使ってドメインの名前変更は可能でした。
さらに、従来と同じ振る舞いを選べるように IF EXISTSオプションが追加されました。
ビューと定義が一致するテーブルを作成することなどが可能となりました。
これまでは EXECUTE を使う場合には WITH DATA が指定できず、カラム名指定もできませんでしたがドキュメントに明記されていませんでした。
以下は以前のエラーになる例です。9.2 バージョンではエラーなく実行できます。
=# PREPARE p1 AS SELECT * FROM t WHERE id = 1; PREPARE =# EXECUTE p1; id | date ----+---------------------------- 1 | 2011-11-24 11:24:49.675427 (1 row) =# CREATE TABLE t1 AS EXECUTE p1; SELECT 1 =# CREATE TABLE t2 AS EXECUTE p1 WITH DATA; ERROR: syntax error at or near "WITH DATA" =# CREATE TABLE t3 (id, v) AS EXECUTE p1; ERROR: column name list not allowed in CREATE TABLE / AS EXECUTE
ビューに対する SELECT文の WHERE句に安全でない関数を与えることで、本来出力されない値が読み出されてしまうケースが知られています。本オプションは、ビューによって保護されていたデータが最適化によって露出してしまうのを防ぎます。
ただし、本オプションを無効にした(デフォルト動作)ビューに比べると性能で劣ります。
関数が security_barrier の働きを有効にしなくとも安全であることを宣言するものです。管理者ユーザのみ属性を付与することができます。
これによって VACUUM の滞留が劇的に減少します。
TIMING オプションを FALSE としたときそのようになります。
元となるデータ型の下限値と上限値の二つの値の組で構成され、含まれるか、重なりがあるか、などの演算子を備えます。
JSON(JavaScript Object Notation)データを格納し、書式が適切であるかチェックされます。
配列、行データからjsonデータ型にそれぞれ変換します。
格納サイズが 2 バイトである以外は、serial型と変わりありません。
このオプションはドメイン定義の作成時か、ALTER DOMAIN ... ADD CONSTRAINT ... NOT VALID によって有効になります。ALTER DOMAIN ... VALIDATE CONS TRAINT で、制約が満たされているか検証することができます。
POSIX で規定された値と符号、通貨記号の順序に従うようになりました。典型的にはユーロ記号が規定どおり金額の後に置かれるようになります。また、3桁ごとの区切り記号が必ず小数点の左側だけに挿入されるようになります。
これまで libxmlライブラリからスカラー値が与えられた場合、空配列が返っていました。また、xpath_exists() で同様の式で false でなく true が返るようになりました。
以前は管理者ユーザのみが使用可能でした。
これにより、データベースの状態を表示した特定のビューを、複数のトランザクションで共有できるようになりました。スナップショットのエクスポートは pg_export_snapshot() 、インポートは SET TRANSACTION SNAPSHOT を用います。インポートは、現在実行中のスナップショットのみが可能です。
並行に同時点のデータを取り出す目的などに利用できます。
=# BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ; BEGIN =# SELECT pg_export_snapshot(); pg_export_snapshot -------------------- 000008F2-1 (1 row) =# SELECT * FROM t1 OFFSET 0; :
=# BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ; BEGIN =# SET TRANSACTION SNAPSHOT '000008F2-1'; SET =# SELECT * FROM t1 OFFSET 100000; :
式に対して、その式の COLLATE をあらわす文字列を返します。
=# SELECT COLLATION FOR ('xxx'::text COLLATE "ja_JP.utf8"); pg_collation_for ------------------ "ja_JP.utf8" (1 row)
これは、現在のトリガーの呼び出し深度を表示します。
以前のバージョンでは最初の後方参照でチェックが行われていませんでした。
以下の2番目は本来 false となるべきです。
9.1.5 バージョンの動作例
=# SELECT 'abc abc abc' ~ '^(w+)( 1)+$'; ?column? ---------- t (1 row) =# SELECT 'abc zzz abc abc' ~ '^(w+)( 1)+$'; ?column? ---------- t (1 row)
これまでは、この列の値は NULL でした。
これまでは、空欄でないデフォルトの権限はビューに表示されませんでした。
引数名での指定もできます。
結果セットの部分的な読み取りが可能となります。
.colnames、.coltypes、.coltypmods が加わりました。
以下のように関数定義の中で引数名をそのまま使うことができます。
=# CREATE FUNCTION fp(param1 int) RETURNS t1 LANGUAGE sql AS $$ SELECT * FROM t1 WHERE id = param1; $$;
このオプションは、pg_hba.conf の認証設定で local、host を別々に制御します。--auth オプションは今までと変わらず、両方の接続方式を制御します。
この機能は、x コマンドの auto オプションで有効となります。
新たに追加された ir コマンドを使用します。
.psqlrc-9.2 という名前にすると 9.2系列で有効になります。
PSQL_HISTORY、PSQLRC でファイル名を指定できます。
これにより、ファイル名でエディタの編集モードが選択される場合に適切なモードを選べるようになります。
様々なシェルツールが、ゼロバイト (0x00、NUL) を区切りに用います(例 find コマンド)。
これまでは、クエリ成功時の所要時間のみが表示されていました。
誤った振る舞いが修正され、より想定される動作をするようになります。また、set ON_ERROR_ROLLBACK の設定を尊重するようになります。
serial型のカラムによって作成されたシーケンスが該当します。
「ALTER TABLE .. ALTER .. SET STATISTICS ..」でカラムごとに設定された統計情報のエントリ数が参照できるようになります。
これらは、dC+ 、dc+ 、dD+ 、dL の出力結果に含まれています。
外部サーバ、外部テーブル、外部データラッパのコメントは、 des+ 、det+ 、dew+ の出力結果に含まれています。
このオプションで、指定したテーブルのテーブル定義のみをダンプできるようになります。
有効値は pre-data、data、post-data です。それぞれ、テーブル定義、データ投入、インデックス作成、が含まれます。これらの一部だけダンプしたり、リストアすることができます。このオプションには複数セクションを指定
可能です。
これにより、ロールの設定がエラーを発生させること無く、他のロールを参照できるようになりました。
これにより、常に同じダンプファイルが作成されます。
pg_restore でリストアする形式のときに出力されるオブジェクト依存関係が改善され、ダンプにあらわれないオブジェクトを経由した間接的な依存関係も表現できます。
以下のような記述形式となります。
postgresql://localhost:5433 postgresql://localhost/mydb postgresql://user@localhost postgresql://user:passwd@localhost postgresql://other@localhost/otherdb?connect_timeout=10
速いネットワークにおけるマシン負荷軽減の目的に利用できます。
これまで libpq は常にクエリ結果全体をメモリに収めていました。
呼び出し元はプロセス終了前にシグナルを受け取ることができるようになります。
dgux、nextstep、sunos4、svr4、ultrix4、univel、bsdi、のサポートが終了となります。
ただし、現時点では使われていません。
ヘッダファイル pg_crc.h、pg_crc_tables.h も追加されます。
この変更は dblink_send_query()、dblink_get_result() 関数には効果がありません。
削除しようとするアーカイブWALのファイル名を出力して終了します。
本ユーティリティを利用することで、サーバシステムの時間単調性や時間測定のオーバヘッドを確認できるようになりました。
本モジュールを利用することで、テーブルデータの変更で、NOTIFY イベント(通知)メッセージを表示させることが可能になりました。
data, bin, port 環境変数は PG から始まる変数名にリネームされました。また、ポート番号を変更するために PGPORTOLD/PGPORTNEW がサポートされました。
処理中にアクセス権が追加のみである4つのログファイルが生成され、処理が成功したら削除されます。-r、--retain オプションを指定することで、処理成功後もログファイルが削除されずに残ります。従来ログファイル出力を
指定していた -g、-G、-l オプションが削除されました。
これにより、移行処理後の統計情報の収集時間を短縮できるようになりました。
指定されたオプション文字列が直接に移行元/先サーバの postgres コマンドのオプションとして付けられます。
具体的には、リンクモードが使われている場合、移行元のみがロックされます。なお、ロック動作はスキーマがリストアされた後に行われます。
ユーザアプリケーションでパラメタ化されていない SQL であっても、詳細なログ分析なしでクエリ性能を監視することが可能になりました。
特にデータベース、テーブルスペース、ロールに対してセキュリティラベルを付与することができます。
「gmake STYLE=website draft」の指定を使用します。
プロトコル説明でMD5認証の部分の記述が改善されました。
PostgreSQL では長い間、これらのキーワードを効果のない物として扱ってきており、これからもそうします。しかし将来、SQL標準で意味をもつものとされる可能性があります。アプリケーションはこれらの使用を避けるべきです。
PostgreSQL 9.2 に関する技術情報は こちらのページ をご覧ください。
2012 年リリース予定の PostgreSQL の新機能について、SRA OSS, Inc. 日本支社にて動作検証を行いましたので、その結果をご報告します。
PostgreSQL 9.2 では機能の追加、性能の向上の両方が行われていますが、本検証では主として機能の追加に関する検証を実施しました。(一部、性能向上の検証も行っています。)
詳しくは、「PostgreSQL 9.2 検証報告」(PDF形式/468KB/21ページ) をご覧ください。
本検証で実施していない重要な拡張点として、「消費電力の軽減」「多CPU性能アップ」などがあります。また、他にも多数の改善がなされており、それらは PostgreSQL 9.2 ドキュメントの リリースノート に記載されています。
性能向上に関する検証につきましては、PostGreSQL 9.2 最新動向セミナーの、講演スライド(PDF 形式PDF形式/325KB/20ページ)をご参照ください。