PostgreSQL 10.22 に関する技術情報

このリリースは 10.21 からの修正リリース（2022年8月11日リリース）です。
10.X からのアップデートではダンプ、リストアは不要です。
しかしながら、10.19 よりも前のバージョンからアップデートする場合には、10.19 のリリース情報も参照してください。

PostgreSQL 10.21 から 10.22 への変更点

14.5、13.8、12.12、11.17、10.22 の各バージョンが同時にリリースされており、本ページでは共通の記載としています。各修正項目が適用されるバージョン系列番号を項目末尾に括弧書きで記載しています。

拡張のスクリプトが、拡張に属していないオブジェクトを置換しないようになりました。 (Tom Lane) (14)(13)(12)(11)(10)

この変更は、拡張に属さない既存オブジェクトがある場合に、拡張のスクリプトが CREATE OR REPLACE を行うことを防止します。また、同じ状況での CREATE IF NOT EXISTS も防止します。これにより、敵対的なデータベースユーザが拡張のオブジェクトの所有者になって、それを変更して将来の他ユーザによるオブジェクト使用を危機にさらすという、トロイの木馬型の攻撃を防ぐことができます。副次的な利点として、意図しないオブジェクトを誤って置換してしまうリスクも軽減されます。(CVE-2022-2625)

スタンバイサーバでの「CREATE DATABASE」WALレコードのリプレイが修正されました。 (Kyotaro Horiguchi, Asim R Praveen, Paul Guo) (14)(13)(12)(11)(10)

スタンバイサーバがデータベース作成の WALレコードをリプレイする時に、テーブルスペースのディレクトリが見つからないことがあります。本パッチ適用前は、このような場合、スタンバイはリカバリに失敗していましたが、このようなディレクトリが合法的に欠落している可能性がありました。テーブルスペースを（通常のディレクトリとして）作成し、リプレイが一貫した状態に達したら、再び削除されていることを確認する動作に変更されました。

「構内」テーブルスペースがサポートされました。 (Thomas Munro, Michael Paquier, Álvaro Herrera) (14)(13)(12)(11)(10)

通常、PostgreSQL のテーブルスペースは、他のファイルシステム上のディレクトリへのシンボリックリンクですが、この変更により、データベースクラスタディレクトリ内の単なるディレクトリにすることができます。

これはテストには便利な仕組みです。さらに、CREATE DATABASE リプレイの修正（前項の修正）で、欠落しているテーブルスペースを構内テーブルスペースとして一時的に作成するために必要となります。

設定パラメータ allow_in_place_tablespaces が追加されています。以下のように使用できます。

（以下を実行すると pg_tblspc 以下にテーブルスペース用ディレクトリが作られる）
db1=# SET allow_in_place_tablespaces TO on;
db1=# CREATE TABLESPACE sp1 LOCATION '';
CREATE TABLESPACE

CREATE INDEX における権限チェックが修正されました。 (Nathan Bossart, Noah Misch) (14)(13)(12)(11)(10)

CVE-2022-1552 むけの修正により、CREATE INDEX が演算子クラスやその他のオブジェクトの検索を実行する際に、以前は呼び出しユーザのパーミッションを適用していたところで、テーブル所有者のパーミッションを適用するようになっていました。pg_dump はパーミッションを再度付与する前に CREATE INDEX を発行するため、これによりダンプ/リストアのシナリオが壊れていました。

本修正で問題を回避するように調整されました。

拡張問い合わせプロトコルでは、トランザクションブロック内で実行できないCREATE DATABASE 等のコマンド後に、即時コミットを強制するようになりました。 (Tom Lane) (14)(13)(12)(11)(10)

クライアントがそのようなコマンドの直後に Sync メッセージを送信せず、代わりに別のコマンドを送信した場合、そのコマンドで障害が発生すると、直前のコマンドがロールバックされ、通常ディスク上に矛盾した状態が残りました（欠落しているデータベースディレクトリや余分なデータベースディレクトリなど）。

そのような状況を防ぐためのメカニズムは、簡易問い合わせメッセージ内の複数コマンドに対しては機能しますが、拡張問い合わせの一連のメッセージに対しては機能しません。現在動作しているユースケースを壊さずに矛盾を防ぐため、そのようなコマンドの後に暗黙のコミットを強制するものとなりました。

トランザクションの可視性をチェックする際の競合状態が修正されました。 (Simon Riggs) (14)(13)(12)(11)(10)

内部実装関数 TransactionIdIsInProgress(xid) が、対象のトランザクションが可視とみなされる前に「false」を報告し、さまざまな誤動作を引き起こす可能性がありました。競合状態のウィンドウは通常、非常に狭いですが、同期レプリケーションを使用すると同期レプリカの待機がそのウィンドウ内で発生するため、より広くなります。

代表的な誤動作は以下のエラーが出ることです。

ERROR:  t_xmin is uncommitted in tuple to be updated

最上位以外に集合を返す関数を含む式でソートした場合の誤った計画が修正されました。 (Richard Guo, Tom Lane) (14)(13)

以下ような形状の問い合わせについて、予期せぬエラー「ERROR: set-valued function called in context that cannot accept a set」が生じるケースが報告されました。

SELECT unnest(ARRAY[]::integer[]) + 1 AS pathkey
  FROM ta JOIN tb ON ta.c1 = tb.c1 ORDER BY pathkey

拡張統計情報の誤った権限検査コードが修正されました。 (Richard Guo) (14)

ユーザが不十分な SELECT権限しか持たないテーブルに拡張統計情報がある場合、一部の問い合わせが「ERROR: permission denied ...」ではなく、「ERROR: unrecognized node type」で失敗していました。

ブール値式の MCV（最頻値）型の統計情報を処理するために、拡張統計情報の仕組みが修正されました。 (Tom Lane) (14)

統計収集は正常に動作しますが、WHERE にその式を含む問い合わせは、プラン作成時に「ERROR: unknown clause type ...」で失敗していました。

（エラー発生例）
db=# CREATE TABLE t9 (a int, b int);
db=# CREATE STATISTICS stat_ex1 ON
       (CASE a WHEN 1 THEN true ELSE false END), b FROM t9;
db=# INSERT INTO t9 SELECT g % 10, g FROM generate_series(1,10000) g;
db=# ANALYZE t9;
db=# SELECT * FROM t9 WHERE (CASE a WHEN 1 THEN true ELSE false END) AND b = 2;

ERROR:  unknown clause type: 134

配列変数に MCV（最頻値）タイプの拡張統計情報がある場合に「constant = ANY(array)」句に対してプランナでクラッシュが生じていて、修正されました。 (Tom Lane) (14)(13)

（障害発生例）
db=# CREATE TABLE t10 (c int, a int[]);
db=# CREATE STATISTICS stat_ex10 (mcv) ON c, a FROM t10;
db=# INSERT INTO t10 SELECT g, ARRAY[g] FROM generate_series(1, 10) g;
db=# ANALYZE t1
db=# SELECT * FROM t10 WHERE c = ANY (ARRAY[1,2,3]) AND 1 = ANY(a);

server closed the connection unexpectedly

「ALTER TABLE ... ENABLE/DISABLE TRIGGER」がパーティションテーブル上のトリガの再帰を正しく処理するように修正されました。 (Álvaro Herrera, Amit Langote) (14)(13)(12)(11)

場合によっては、コマンドがトリガを持たない子パーティションでトリガを調整しようとするため、「ERROR: trigger does not exist」が発生することがありました。

拡張統計情報の計算中に ANALYZE をキャンセルできるようになりました。 (Tom Lane, Justin Pryzby) (14)

高コストな統計情報対象を伴うシナリオでは、キャンセルできないソート操作に何秒も費やす可能性がありました。

jsonpath型の構文エラーメッセージが改善されました。 (Andrew Dunstan) (14)(13)(12)

「ERROR: syntax error, unexpected IDENT_P at or near " " of jsonpath input」のような、パーサ実装のトークン名を伴うメッセージが出ていました。

pg_stop_backup() がセッションの状態を適切にクリーンアップするようになりました。 (Fujii Masao) (14)(13)(12)(11)(10)

これまで省略されていたため、セッションの後半でアサート失敗やクラッシュを引き起こす可能性がありました。

ゼロ次元の配列の引数を適切に処理するように trim_array() が修正されました。 (Martin Kalcher) (14)

不正メモリアクセスにより、潜在的にクラッシュが生じる可能性がありました。

「FOR [KEY] UPDATE/SHARE」句における結合エイリアスのマッチングが修正されました。 (Dean Rasheed) (14)(13)(12)(11)(10)

稀なケースでは、誤解を招くエラーが報告されることがありました。

「ERROR: FOR UPDATE cannot be applied to a join」とするべきところで、「ERROR: relation "..." in FOR UPDATE clause not found in FROM clause」が出力される動作が報告されました。

多すぎる列を持つ FROM の中の ROW() 表現と関数を拒絶するようになりました。 (Tom Lane) (14)(13)(12)(11)(10)

おおよそ 1600列を超えるケースはサポートされておらず、必ず実行に失敗します。しかしながら、32K を超える列を持った問い合わせによって、アサート失敗またはクラッシュが発生する以前のコードが一部ありました。これを避けるために構文解析するときに検査するようになりました。

ビューが作られて複合型の列がドロップされた場合、複合型を返す FROM の中の関数を使っているビューのダンプが修正されました。 (Tom Lane) (14)(13)(12)(11)(10)

ダンプされたビューはこの関数に対する過剰な列エイリアスを持っているため、ダンプ／リストアや pg_upgrade でのエラーを引き起こしました。

（障害動作例）
db=# CREATE TYPE typ18 AS (c1 int, c2 int, c3 int);
db=# CREATE VIEW v18 AS SELECT * FROM fn18();
db=# ALTER TYPE typ18 DROP ATTRIBUTE c2;
db=# SELECT pg_get_viewdef('v18', true); -- ダンプ時の出力を確認
          pg_get_viewdef
----------------------------------
  SELECT fn18.c1,                +
     fn18.c2,                    +
     fn18.c3                     +
    FROM fn18() fn18(c1, c2, c3);
(1 row)
db=# SELECT fn18.c1, fn18.c2, fn18.c3 FROM fn18() fn18(c1, c2, c3);
ERROR:  table "fn18" has 2 columns available but 3 columns specified

論理レプリケーションの walsender で、同セッション内からの入れ子のベースバックアップ取得処理を禁止するようになりました。 (Fujii Masao) (14)(13)(12)(11)(10)

クラッシュやアサート失敗を起こす可能性がありました。

論理レプリケーションのサブスクライバのメモリリークが修正されました。 (Hou Zhijie) (14)(13)(12)(11)(10)
ターゲットテーブルがパーテション化されている場合、論理レプリケーションのレプリカアイデンティティ（REPLICA IDENTITY）の検査が修正されました。 (Shi Yu, Hou Zhijie) (14)(13)

子パーティションについてのレプリカアイデンティティ列の検査が抜け落ちていました。

サブスクライバ側でアサート失敗を引き起こす動作が報告されました。

論理レプリケーションにおいてパブリッシャのスキーマを変更した後にサブスクライバでキャッシュされたスキーマデータの更新に失敗していて、これが修正されました。 (Shi Yu, Hou Zhijie) (14)(13)
「BRIN_EVACUATE_PAGE」フラグを正しく処理するように、WAL一貫性の検査ロジックが修正されました。 (Haiyang Wang) (14)(13)(12)(11)(10)
共有ハッシュテーブル管理における誤ったアサート検査が修正されました。 (Thomas Munro) (14)(13)(12)(11)
min_dynamic_shared_memory がデフォルトでない値にセットされた時に起きるアサート失敗が回避されました。 (Thomas Munro) (14)
SPI_commit() のなかでコミット時のエラーが起きた時、呼び出し元がクリーンアップしてくれることを期待せずに自動で行うようになりました。 (Peter Eisentraut, Tom Lane) (14)(13)(12)(11)

適切なクリーンアップには複雑で低レベルな機能を必要とします。従って、どの既知の呼び出し元もクリーンアップしないことがあり得ます。このために、手続き言語が COMMIT を発行したが（例えば遅延制約検査などで）エラーが起きてしまった場合に誤動作を招きます。

これを改善するために SPI_commit() を次のように再定義しました。即ち、前トランザクションの特性を保存せずに新しいデフォルトトランザクションの特性を取ること以外は、SPI_commit_and_chain() と等価な新しいトランザクションを開始するものとしました。この変更を透過的にするため、SPI_start_transaction() を no-op（何もしない動作）に再定義しました。全ての SPI_commit() の既知の呼び出し元は直後に SPI_start_transaction() を呼びます。これにより全ての呼び出し元は本変更の影響を受けません。同じ変更は SPI_rollback() にも行われています。

PL/Python の修正も行われました。PL/Python では、このようなエラー処理が完全に省略されていて、Python 3.11 ではクラッシュすると報告されており、古いバージョンでは何も問題ないように見えますがメモリリークが起きます。

パイプラインモードでの libpq のアイドル状態の処理が改善されました。 (Álvaro Herrera, Kyotaro Horiguchi) (14)

時々「WARNING: message type 0x33 arrived from server while idle」が出る動作が報告されていました。また、PQgetResult() から問い合わせの最後の NULL の結果が失われる可能性がありました。

ecpglib で予想外の順序の操作でのクラッシュが回避されました。 (Tom Lane) (14)(13)(12)(11)(10)

EXEC SQL PREPARE などの特定の操作をデータベース接続を確立する前に呼び出すと、エラーを報告するのではなくクラッシュしました。

ecpglib で冗長な newlocale() 呼び出しが回避されました。 (Noah Misch) (14)(13)(12)(11)(10)

クエリごとにロケールオブジェクトを作成して解放するのではなく、最初の接続時にプロセスごとに C ロケールオブジェクトを割り当てるように修正されました。これにより、AIX における libc のメモリリークが軽減され、また、どのプラットフォームでも性能向上が見込まれます。

psql の \watch コマンドで、Ctrl-C でキャンセルした後に改行をエコーするようになりました。 (Pavel Stehule) (14)(13)(12)(11)(10)

これにより、libedit (およびおそらく libreadline) でカーソルがどの列にあるかについて混乱するのを防ぎます。

（動作例）
db=# SELECT 1;
 ?column?
----------
        1
(1 row)

db=# \watch
2022年08月16日 07時53分10秒 (every 2s)

 ?column?
----------
        1
(1 row)

（修正前の動作）
^Cdb=#

（修正後の動作）
^C
db=#

pg_upgrade がアップグレード不可能な anyarray を取る関数を検出するように修正されました。 (Justin Pryzby) (14)

バージョン 14 では、いくつかの組み込み関数が、anyarray ではなく anycompatiblearray 型を取るように変更されました。これはほとんど透過的ですが、これらの関数の上に構築されたユーザ定義の集約関数と演算子は、正確に一致する型で宣言する必要があります。古いシグネチャを参照するオブジェクトが存在すると、pg_upgrade が失敗する原因となるため、アップグレードを開始する前に、そのようなケースを検出して報告するように変更されました。

(修正後の動作)
$ pg_upgrade -b /usr/local/pgsql-13.8/bin -B /usr/local/pgsql-14.5/bin \
    -d /usr/local/pgsql-13.8/data -D /usr/local/pgsql-14.5/data
Performing Consistency Checks
-----------------------------
Checking cluster versions                                   ok
Checking database user is the install user                  ok
Checking database connection settings                       ok
Checking for prepared transactions                          ok
Checking for system-defined composite types in user tables  ok
Checking for reg* data types in user tables                 ok
Checking for contrib/isn with bigint-passing mismatch       ok
Checking for user-defined encoding conversions              ok
Checking for user-defined postfix operators                 ok
Checking for incompatible polymorphic functions             fatal

Your installation contains user-defined objects that refer to internal
polymorphic functions with arguments of type "anyarray" or "anyelement".
These user-defined objects must be dropped before upgrading and restored
afterwards, changing them to refer to the new corresponding functions with
arguments of type "anycompatiblearray" and "anycompatible".
A list of the problematic objects is in the file:
    incompatible_polymorphics.txt

Failure, exiting
$ cat incompatible_polymorphics.txt
In database: postgres
  aggregate: public.array_accum(anyelement)

pg_upgrade で --clone オプションを使用した場合に、clone() が失敗した後に誤った（OSからの）エラーメッセージが報告される可能性があり、修正されました。 (Justin Pryzby) (14)(13)(12)
contrib/pg_stat_statements が 32 ビットプラットフォームでの巨大な（数ギガバイトの）問い合わせ文字列ファイルでの整数オーバフローを回避するように修正されました。 (Tom Lane) (14)(13)(12)(11)(10)

これに伴って、pg_stat_statements.max の最大値が 2147483647 から 1073741823 に変更されました。

contrib/postgres_fdw で「WITH CHECK OPTION」制約がある場合に一括挿入を防止するようになりました。 (Etsuro Fujita) (14)

外部テーブルのビューが WITH CHECK OPTION 制約を持つ場合、リモートで挿入されるデータを取得し、制約をチェックしますが、一度に複数の行が挿入されると、最初の 1行しかリモートのデータを取得できず、残りの行はローカルのデータで制約をチェックしていました。そのため、リモートのテーブルが行単位 BEFORE INSERT トリガをもち、リモートでデータが変更される場合、制約を適切にチェックできませんでした。

db=# CREATE SERVER loopback
       FOREIGN DATA WRAPPER postgres_fdw OPTIONS (dbname 'db');
db=# CREATE USER MAPPING FOR CURRENT_USER SERVER loopback;
db=# CREATE FUNCTION row_before_insupd_trigfunc()
       RETURNS trigger LANGUAGE plpgsql AS $$
         BEGIN NEW.a := NEW.a + 10; RETURN NEW; END; $$;
db=# CREATE TABLE base_tbl (a int, b int);
db=# CREATE TRIGGER row_before_insupd_trigger
       BEFORE INSERT OR UPDATE ON base_tbl FOR EACH ROW
       EXECUTE PROCEDURE row_before_insupd_trigfunc();
db=# CREATE FOREIGN TABLE foreign_tbl (a int, b int)
       SERVER loopback OPTIONS (table_name 'base_tbl');
db=# CREATE VIEW rw_view AS
       SELECT * FROM foreign_tbl WHERE a < b WITH CHECK OPTION;
db=# ALTER SERVER loopback OPTIONS (ADD batch_size '10');

（修正前の動作: Batch Size が 10 のまま、
  2行目の挿入が変更前データでチェックされ、制約違反のデータが格納される）
db=# EXPLAIN (VERBOSE, COSTS OFF) INSERT INTO rw_view VALUES (0, 15), (0, 5);
                                   QUERY PLAN
--------------------------------------------------------------------------------
 Insert on public.foreign_tbl
   Remote SQL: INSERT INTO public.base_tbl(a, b) VALUES ($1, $2) RETURNING a, b
   Batch Size: 10
   ->  Values Scan on "*VALUES*"
         Output: "*VALUES*".column1, "*VALUES*".column2
 Query Identifier: -8082510435137086002
(6 rows)

db=# INSERT INTO rw_view VALUES (0, 15), (0, 5);
INSERT 0 2

（修正後の動作: Batch Size が 1 になり、
  2行目の挿入が変更後のデータでチェックされ、制約違反でエラーになる）
db=# EXPLAIN (VERBOSE, COSTS OFF) INSERT INTO rw_view VALUES (0, 15), (0, 5);
                                   QUERY PLAN
--------------------------------------------------------------------------------
 Insert on public.foreign_tbl
   Remote SQL: INSERT INTO public.base_tbl(a, b) VALUES ($1, $2) RETURNING a, b
   Batch Size: 1
   ->  Values Scan on "*VALUES*"
         Output: "*VALUES*".column1, "*VALUES*".column2
 Query Identifier: 9094516644014608466
(6 rows)

db=# INSERT INTO rw_view VALUES (0, 15), (0, 5);
ERROR:  new row violates check option for view "rw_view"
DETAIL:  Failing row contains (10, 5).

contrib/postgres_fdw が非同期データフェッチクエリの送信失敗を検出するように修正されました。 (Fujii Masao) (14)
contrib/postgres_fdw が regconfig およびその他の reg* タイプの定数を適切なスキーマ pg_catalog 修飾で送信するようになりました。 (Tom Lane) (14)(13)(12)(11)(10)
Linux で動的共有メモリの割り当て中にシグナルをブロックするようになりました。 (Thomas Munro) (14)(13)(12)(11)(10)

これにより、シグナルが posix_fallocate() に割り込むときのバスエラー (SIGBUS) が回避されます。

shm_open() からの予期しない「EEXIST」エラーを検出するようになりました。 (Thomas Munro) (14)(13)(12)(11)(10)

これにより、Solaris で発生する可能性のあるクラッシュが回避されます。

オープンソースの Unix 系 OS illumos では signalfd() を使用しないようになりました。 (Thomas Munro) (14)

これにより、ハングアップやカーネルパニックが発生するように見えるため、修正が利用可能になるまでこの機能は使用されません。

複合型に対するドメインを返す関数の結果を行全体の変数で参照する問い合わせ処理が修正されました。 (Tom Lane) (13)(12)(11)

（修正前のエラー動作例）
db=# CREATE TYPE ctyp4 AS (c1 boolean, c2 boolean);
db=# CREATE DOMAIN dom4 AS ctyp4 NOT NULL;
db=# CREATE FUNCTION f_ctyp4() RETURNS ctyp4 LANGUAGE sql
     AS $$ SELECT (true, true) $$;
db=# CREATE FUNCTION f_dom4() RETURNS dom4 LANGUAGE sql
     AS $$ SELECT (true, true) $$;

（複合型を返す場合は動作する）
db=# SELECT f_ctyp4 FROM f_ctyp4();
 f_ctyp4
------------------------
 (t,t)
(1 row)

（複合型のドメインを返す場合にエラーになっていた - 修正後は動作する）
db1=# SELECT f_dom4 FROM f_dom4();
ERROR:  type dom4 is not composite

プランナで GROUPING 関数で参照されている副問い合わせをプルアップする（上位の問い合わせに統合する）ときに、「ERROR: variable not found in subplan target list」が生じる問題が修正されました。 (Richard Guo) (13)(12)(11)(10)

（修正前バージョンでのエラー発生例）
db=# CREATE TABLE t5 AS SELECT generate_series(1, 100)::int i ;
db=# SELECT GROUPING(ss.x) FROM t5 CROSS JOIN LATERAL (
       SELECT (SELECT t5.i) as x) ss GROUP BY ss.x;
ERROR:  variable not found in subplan target list

pg_stat_get_subscription() 関数がゴミデータを含んだ追加の行を返す可能性があり、防止されました。 (Kuntal Ghosh) (13)(12)(11)(10)

pg_stat_get_subscription() 関数は pg_stat_subscription ビューから使われます。

XMLTABLE や JSON_TABLE に多すぎる列別名を付加した場合のクラッシュが回避されました。 (Álvaro Herrera) (13)(12)(11)(10)

そのような問い合わせに適切なエラーを返すようになりました。これまでは奇妙なエラーが出たり、クラッシュしたりしていました。

（修正後の動作、f(v1,v2) で実際の列数より多く別名が指定されている）
db=# SELECT * FROM XMLTABLE (ROW () PASSING null COLUMNS v1 timestamp)
     AS f (v1, v2);
ERROR:  XMLTABLE function has 1 columns available but 2 columns specified

（修正前のエラーメッセージ）
ERROR:  no relation entry for relid 0

ビューやルールを（ダンプ出力や psql での表示のため）逆コンパイルする際、それが他で参照されうる場合には、SELECT 出力列の「AS "?column?"」別名句を見せるようになりました。 (Tom Lane) (13)(12)(11)(10)

これまでは、自動生成されたこの別名は常に隠されていましたが、結果としてビューやルールがリストア不能になる稀なケースがありました。

暗黙的に作成された演算子族がイベントトリガに通知されるようになりました。 (Masahiko Sawada) (13)(12)(11)(10)

以前は、CREATE OPERATOR CLASS によって演算子族が暗黙的に作成された場合、イベントトリガに通知されませんでした。

スタンバイサーバの昇格中にリスタートポイントが実行されている時に行われるコントロールファイルの更新が、修正されました。 (Kyotaro Horiguchi) (13)(12)(11)(10)

以前は、リスタートポイント完了時にコントロールファイルの最終チェックポイントのフィールドが誤って更新される可能性があり、次の通常チェックポイント完了前にサーバがクラッシュした場合、PANIC が発生して再起動に失敗する可能性がありました。

大規模トランザクションの論理レプリケーション中に、スタンバイの wal_receiver_timeout を発動させないようになりました。 (Wang Wei, Amit Kapila) (13)(12)(11)(10)

以前は、プライマリサーバ上の大規模トランザクションが（おそらく変更されたテーブルがパブリッシュされていないために）スタンバイにデータを送信しない場合、スタンバイがタイムアウトする可能性がありました。キープアライブメッセージを定期的に送信することで修正されました。

無効なタイムゾーン省略形ファイルを読み取る際のファイルクローズ漏れが防止されました。 (Kyotaro Horiguchi) (13)(12)(11)(10)

このような場合には無害な警告メッセージが生じることがありました。

カスタムサーバパラメータの短い説明に NULL を指定できるようになりました。 (Steve Chavez) (13)(12)(11)(10)

短い説明は SHOW ALL の description などに表示されるもので、以前は、拡張でここに NULL を指定していると表示処理がクラッシュしていました。

libpq で SSL 秘密鍵の誤った所有者チェックが削除されました。 (Tom Lane) (13)(12)(11)(10)

以前のマイナーリリースで、サーバでの SSL 秘密鍵のアクセス権チェック方式を libpq にも適用しましたが、所有者チェックまで同様に行うべきではありませんでした。鍵ファイルにアクセス可能であるけれども所有者と異なるユーザでクライアントを実行するときに、予期せぬエラーが生じることがありました。

(エラー例: root で root 以外のユーザが所有者の鍵ファイルを指定して psql を実行）
$ su -
# PGSSLCERT=/ssl/cert.pem PGSSLKEY=/ssl/key.pem PGSSLROOTCERT=/ssl/rcert.pem \
  PGSSLMODE=verify-ca psql -h localhost -U postgres -d postgres
psql: error: private key file "key.pem" must be owned by the current user or root

ecpg でサーバ接続が失われた場合のエラーを適切に報告するようになりました。 (Tom Lane) (13)(12)(11)(10)

接続が失われた場合などに、libpq で生成されたエラー結果を誤って処理していたため、有用なエラーメッセージではなく「(null)」と出力されていました。また、古いリリースではクラッシュする可能性がありました

PL/Perl のテストケースが Perl 5.36 で動作するように調整されました。 (Dagfinn Ilmari Mannsaker) (13)(12)(11)(10)
PostgreSQL ビルド中に複数の OpenLDAP がインストールされている場合に、古い libldap_r ライブラリを誤って使用しないように configure が修正されました。 (Tom Lane) (13)(12)(11)(10)
論理レプリケーションでマテリアライズドビューのヒープ書き換え一時テーブルを無視するようになりました。 (Euler Taveira) (10)

「FOR ALL TABLES」指定のパブリケーションは、個別にテーブルを指定せず、全テーブルが複製対象となり、一時テーブルを複製しようとします。DDL 中のヒープ書き換え一時テーブルは除外されますが、マテリアライズドビューの書き換え中に作成された内部一時テーブルをカバーできませんでした。これにより、REFRESH MATERIALIZED VIEW 中に「logical replication target relation ... does not exist」というエラーが発生するリスクがありました。

SRA OSSでは、PostgreSQL/Pgpool-II のサポートを提供しております。
詳しくは弊社ホームページをご覧ください。

PostgreSQL 10.22 に関する技術情報

PostgreSQL 10.21 から 10.22 への変更点

最近の投稿

カテゴリー

PostgreSQL 10.21 から 10.22 への変更点

関連記事:

最近の投稿

カテゴリー

タグ