PostgreSQL 19の新機能と変更点｜RC1時点の一覧と移行の確認SQL

この記事で実際に動かしたもの：手元の PostgreSQL 16.15 を作業用のディレクトリに initdb して 127.0.0.1 で起動し、19 の新しい構文を流したときのエラー原文、16 での代わりの書き方の出力、VACUUM FULL のロック待ち・NOT IN の遅さ・TOAST の圧縮の実測、19 の pg_upgrade が拒否する条件を探す SQL を実行しました。19 本体は、npm・PyPI に 19 のバイナリが無く、公式の配布サイトにはこの環境から接続できなかったため動かしていません（19 の動きは公式の範囲）。

flowchart TD
    A[6/4 Beta 1] --> B[Beta 2〜4<br>一部の機能を取り下げ]
    B --> C[10/15 RC 1<br>いまの最新]
    C --> D[11/12 RC 2 予定]
    D --> E[11/19 正式版 19.0 予定]
    C -.-> F[11/12 14系のサポート終了]

よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.5 LTS（x86_64、2 CPU）の上で、Ubuntu のパッケージの PostgreSQL 16.15（psql・pg_dump・pg_upgrade・pg_basebackup も 16.15）を使い、/dev/shm の作業ディレクトリに initdb したクラスタを 127.0.0.1:54291 で起動しました（max_connections = 10・shared_buffers = 64MB、ほかは既定値）。スタンバイの実験は同じマシンの 127.0.0.1:54293 に pg_basebackup で作ったストリーミングレプリカです。19 は、npm（@embedded-postgres/linux-x64 は 18.6.0 まで）・PyPI（postgresql-binaries・embedded-postgres は 18.6 まで）に配布物が無く、apt.postgresql.org・Docker Hub にはこの環境から接続できなかったため、ソースからのビルドはせず公式の範囲で書いています。19 の事実は、postgresql.org の「PostgreSQL 19 RC 1 Released!」（10月15日）・「PostgreSQL 19 Beta 1 Released!」（6月4日）、19 のリリースノート（RC 1 時点、ページ上の表記は「AS OF 2026-10-09」）、19 のドキュメント（REPACK・WAIT・INSERT・COPY・ウィンドウ関数・pg_plan_advice）、バージョンのサポート方針のページ、PostgreSQL 19 Open Items（公式 wiki）で1つずつ確かめました。図は mermaid 11.16.0 で描画を確かめています（確認日 2026年11月5日）。

PostgreSQL 19とは（何が・いつ・誰に・いくらで）

この節では、PostgreSQL 19 がどんな版で、いつ・どこから手に入るのかが1枚の表で分かります。

PostgreSQL 19 は、PostgreSQL Global Development Group が毎年1回出すメジャーバージョンの2026年版です。18（2025年9月25日公開）の次の版で、保守の楽さ（REPACK・並列 autovacuum）、レプリカの読み取りの正しさ（WAIT）、プランナーの改善（NOT IN の変換など）が中心です。

19 の版の文字列は、RC 1 では 19rc1 のように付きます。手元の版は SELECT version(); で確かめられます。16.15 で実行すると次のように出ました。

SELECT version();
 PostgreSQL 16.15 (Ubuntu 16.15-0ubuntu0.24.04.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0, 64-bit
(1 row)

PostgreSQL 19のリリース日と今の状態（RC 1・取り下げられた機能）

この節では、19 がいまどの段階にあり、Beta 1 の発表から何が外れたのかが分かります。

RC 1 の公式発表には「一般提供は2026年11月19日を予定。問題で延期や追加の RC が要る場合を除く」と書かれています。RC 2 を11月12日（サポート中の版の定例の更新日）に出し、その更新の修正を多く 19 にも入れてから正式版にする、という順番です。

RC 1 で Beta 4 から変わったこと

公式発表に挙がっている RC 1 の主な修正は次のとおりです。

• REPACK (CONCURRENTLY) の修正（複数）
• pg_plan_advice の修正（複数）
• 式が NULL になりうるかに頼る新しいプランナーの最適化の修正
• wal_level = replica のときの論理レプリケーションの自動有効化の修正
• postgres_fdw の統計の取り込みを、ANALYZE を実行した人ではなく外部テーブルの所有者で動かすように修正
• 並列 autovacuum の修正
• COPY (query) TO ... (FORMAT json) の JSON のキーを、表の列名ではなく問い合わせの列名（別名を含む）にする修正

Beta 1 にあって RC 1 のリリースノートに無い機能

6月4日の Beta 1 の発表には載っていたものの、RC 1 のリリースノートには載っていない機能があります。PostgreSQL 19 Open Items（公式 wiki）には、SQL/PGQ・FOR PORTION OF・MERGE/SPLIT PARTITIONS・pg_get_*_ddl() の項目に「reverted（差し戻し）」の印が付いています。

Beta の時期に書かれた解説には、これらが「19 の新機能」として載っていることがあります。19 で使う予定の機能は、19 のリリースノート（postgresql.org/docs/19/release-19.html）にあるかで確かめるのが確実です。

PostgreSQL 19の新機能一覧（16・17・18 での代わりの書き方つき）

この節では、19 の主な新機能と、19 より前の版で同じことをするときの書き方が一覧で分かります。

リリースノートの「Overview」に挙がっている柱は7つです。REPACK、pg_plan_advice、I/O ワーカーの自動増減などの性能改善、wal_level = replica での論理レプリケーションの有効化、シーケンスの論理レプリケーション、WAIT、並列 autovacuum とスコアでの優先順位付けです。

19 の新しい構文は、16 では構文エラーになります。手元の 16.15 で流した原文です（どの版で動いているかを確かめるときの目印になります）。

REPACK emp;
ERROR:  syntax error at or near "REPACK"
LINE 1: REPACK emp;
        ^
WAIT FOR LSN '0/0306EE20';
ERROR:  syntax error at or near "WAIT"
LINE 1: WAIT FOR LSN '0/0306EE20';
        ^
INSERT INTO emp VALUES (1,'suzuki') ON CONFLICT (id) DO SELECT RETURNING *;
ERROR:  syntax error at or near "SELECT"
LINE 1: ... INTO emp VALUES (1,'suzuki') ON CONFLICT (id) DO SELECT RET...
                                                             ^
CHECKPOINT (MODE FAST);
ERROR:  syntax error at or near "("
LINE 1: CHECKPOINT (MODE FAST);
                   ^

REPACKとREPACK CONCURRENTLY（VACUUM FULLとの違い）

この節では、REPACK が何を解決するのかを、16 の VACUUM FULL で測ったロック待ちとサイズの実物で分かります。

REPACK は、表とその索引をまるごと書き直して、削除した行の分の領域を OS に返すコマンドです。19 では VACUUM FULL と CLUSTER をまとめた後継で、2つのコマンドも互換のために残ります。違いは CONCURRENTLY で、作業の大半を SHARE UPDATE EXCLUSIVE ロックで行い、ファイルを入れ替える最後だけ ACCESS EXCLUSIVE ロックを取ります。

16 で測った：VACUUM では小さくならず、VACUUM FULL で小さくなる

200,000行（1行あたり約200バイト）の表から9割を削除し、VACUUM と VACUUM FULL のあとのサイズを測りました。

INSERT INTO logs SELECT g, repeat('x', 200) FROM generate_series(1,200000) g;
INSERT 0 200000
SELECT pg_size_pretty(pg_total_relation_size('logs')) AS before_delete;
 before_delete
---------------
 50 MB
DELETE FROM logs WHERE id % 10 <> 0;
DELETE 180000
VACUUM logs;
 after_vacuum
--------------
 50 MB
VACUUM FULL logs;
 after_vacuum_full
-------------------
 5176 kB

VACUUM は空いた場所を再利用できるようにするだけで、ファイルは50MBのままです。VACUUM FULL（19 なら REPACK）で 5,176kB まで縮みました。

16 で測った：VACUUM FULL の間は SELECT も待たされる

1つ目のセッションが表を読んでいる間に VACUUM FULL を始め、さらに3つ目のセッションから SELECT count(*) を流して、pg_locks を見ました。

 pid  |        mode         | granted |                  query
------+---------------------+---------+------------------------------------------
 5531 | AccessShareLock     | t       | BEGIN; SELECT count(*) FROM logs; SELECT
 5537 | AccessExclusiveLock | f       | VACUUM FULL logs
 5541 | AccessShareLock     | f       | SELECT count(*) FROM logs
(3 rows)

 count
--------
 220000
(1 row)
Time: 3304.397 ms (00:03.304)

VACUUM FULL が ACCESS EXCLUSIVE ロックを待つ列に並ぶと、そのあとに来た普通の SELECT（AccessShareLock）も後ろに並び、3.3秒待たされました。大きな表では、この待ちが VACUUM FULL の全体の時間に伸びます。REPACK (CONCURRENTLY) はこの待ちを最後の入れ替えの短い時間だけにするための機能です。

19 の REPACK の書き方（公式の例）

REPACK employees;                              -- VACUUM FULL と同じ
REPACK employees USING INDEX employees_ind;    -- CLUSTER と同じ（索引の順に並べる）
REPACK (CONCURRENTLY) employees USING INDEX;   -- 読み書きを止めずに
REPACK (ANALYZE, VERBOSE) cases (district, case_nr);
REPACK (VERBOSE) USING INDEX;                  -- クラスタ索引を持つ表をすべて

CONCURRENTLY が使えない条件が公式ドキュメントに並んでいます。導入前に表ごとに確かめる項目です。

• 1主キーか、索引による REPLICA IDENTITY がある無い表は CONCURRENTLY を使えない。変更は論理デコーディングで拾うため
• 2普通の表（heap）で、UNLOGGED・パーティション親・マテビューではないシステムカタログ・TOAST 表・user_catalog_table も対象外
• 3トランザクションブロックの外で流すBEGIN の中では使えない
• 4max_repack_replication_slots に空きがあるレプリケーションスロットを1つ作るため
• 5途中で同じ表に DDL を流さない失敗することがある。約1億400万行を超える同時の更新・削除でも失敗する

公式ドキュメントには「MVCC として安全ではない」という警告もあります。REPACK の開始前に取ったスナップショットで読むトランザクションからは、終わったあとの表が空に見えることがあります。長い REPEATABLE READ のバッチと同時に流さない運用にします。VACUUM と autovacuum の監視は、関連記事「PostgreSQLのVACUUMとautovacuum｜監視SQLと設定値の目安」で扱っています。

WAIT FOR LSN（スタンバイで書いた直後の行を読む）

この節では、非同期レプリカで「更新したのに前の値が見える」問題を、16 で再現した様子と 19 の WAIT で分かります。

WAIT は、指定した LSN（WAL の位置）までスタンバイが反映するのを待つコマンドです。プライマリで書いたあとに pg_current_wal_insert_lsn() を控え、スタンバイで WAIT FOR LSN '…' を流してから読むと、自分の書き込みが見える状態で読めます（read-your-writes）。

16 で再現した：書いた直後のスタンバイでは前の値が見える

スタンバイに recovery_min_apply_delay = '1500ms' を設定して遅れを作り、プライマリで100行を更新した直後にスタンバイで読みました。WAIT の代わりに pg_last_wal_replay_lsn() を繰り返し問い合わせています。

primary  : UPDATE 100 -> pg_current_wal_insert_lsn = 0/200156C0
standby  : replay_lsn = 0/20013340, Drama rows = 100
polls    : 27
standby  : replay_lsn = 0/200156C0, Drama rows = 0

real	0m2.651s

更新の直後は、スタンバイの反映位置（0/20013340）が書き込みの位置（0/200156C0）より手前で、更新前の100行が見えました。位置が追いつくまで27回問い合わせ、そのあとは0行（更新後）になりました。遅れの無い状態（設定なし）では、同じ手順で問い合わせは0回でした。

19 の WAIT の書き方（公式の例）

-- プライマリで
UPDATE movie SET genre = 'Dramatic' WHERE genre = 'Drama';
SELECT pg_current_wal_insert_lsn();          -- 例：0/0306EE20

-- スタンバイで
WAIT FOR LSN '0/0306EE20';                     -- status = success
WAIT FOR LSN '0/0306EE20' WITH (MODE 'standby_flush');
WAIT FOR LSN '0/0306EE20' WITH (TIMEOUT '100ms', NO_THROW);  -- status = timeout も返す

戻り値は success・timeout・not in recovery の3つです。TIMEOUT を付けない（または0）と無期限に待つので、アプリから使うときは TIMEOUT と NO_THROW を付け、timeout ならプライマリで読み直すといった逃げ道を作ります。公式ドキュメントでは、WAIT は関数・DO ブロックの中では使えず、ロックを持った状態では拒否されるため「トランザクションの外か、最初の文として流す」とされています。

INSERT ON CONFLICT DO SELECT（入れるか既存の行を返す）

この節では、「無ければ作って、あればその行を返す」を 19 では1文で書けること、16 での書き方とその落とし穴が分かります。

ON CONFLICT DO SELECT は、ぶつかった既存の行を RETURNING で返す新しい動作です。公式は「idempotent insert」「get or create」と呼んでいます。RETURNING と conflict_target（どの一意制約か）が必須で、FOR UPDATE などで返す行をロックすることもできます。

16 では DO NOTHING だと何も返らない

INSERT INTO distributors VALUES (11,'Other Name') ON CONFLICT (did) DO NOTHING RETURNING *;
 did | dname
-----+-------
(0 rows)

INSERT 0 0

既存の行があると RETURNING は0行で、ID を取りたいアプリはもう1回 SELECT を投げることになります。16 で1文にまとめるなら CTE を使います。

WITH ins AS (
  INSERT INTO distributors VALUES (11,'Other Name')
  ON CONFLICT (did) DO NOTHING
  RETURNING *, 'inserted' AS how
)
SELECT * FROM ins
UNION ALL
SELECT *, 'existing' FROM distributors WHERE did = 11 AND NOT EXISTS (SELECT 1 FROM ins);

 did |       dname        |   how
-----+--------------------+----------
  11 | Global Electronics | existing
(1 row)

この書き方は、同じ瞬間に別のトランザクションが同じ行を入れてまだ確定していないと、どちらの枝にも行が出ないことがあります（後半の SELECT は自分のスナップショットで読むため）。DO UPDATE SET dname = EXCLUDED.dname で必ず行を返す方法もありますが、行を書き換えるので WAL と行のバージョンが増えます。19 の DO SELECT は書き換えずに既存の行を返します。

19 の書き方（公式の例）

INSERT INTO distributors (did, dname) VALUES (11, 'Global Electronics')
    ON CONFLICT (did) DO SELECT
    RETURNING *;

INSERT INTO distributors (did, dname) VALUES (13, 'Advanced Systems')
    ON CONFLICT (did) DO SELECT FOR UPDATE
    RETURNING *;

権限は SELECT が要り、FOR UPDATE/SHARE を付けると少なくとも1列の UPDATE 権限も要ります。排他制約は判定に使えません。UPSERT の書き方の全体は、関連記事「SQL UPSERTの書き方｜PostgreSQL・MySQL・MERGE構文比較表」で扱っています。

SQLの追加（IGNORE NULLS・COPYのJSON出力・関数と型）

この節では、毎日の SQL に効く小さな追加と、16 での代わりの書き方の出力が分かります。

ウィンドウ関数の IGNORE NULLS

19 では lag・lead・first_value・last_value・nth_value に IGNORE NULLS / RESPECT NULLS（既定）を付けられます。「直前の NULL でない値で埋める」が1つの関数で書けます。16 では構文エラーです。

SELECT lag(v) IGNORE NULLS OVER (ORDER BY t) FROM (VALUES (1,10),(2,NULL)) s(t,v);
ERROR:  syntax error at or near "NULLS"

16 では、NULL でない値の数を数えて組を作り、組の先頭の値を取ります。

SELECT ts, price,
       first_value(price) OVER (PARTITION BY grp ORDER BY ts) AS last_non_null
FROM (SELECT ts, price, count(price) OVER (ORDER BY ts) AS grp FROM quotes) s
ORDER BY ts;

 ts | price | last_non_null
----+-------+---------------
  1 |   100 |           100
  2 |       |           100
  3 |       |           100
  4 |   130 |           130
  5 |       |           130

19 では last_value(price) IGNORE NULLS OVER (ORDER BY ts) の1つで同じ列になる書き方です（19 での出力は公式の範囲）。

COPY TO の JSON 出力

19 の COPY は FORMAT json を選べます（COPY TO だけ）。FORCE_ARRAY を付けると全体を1つの配列にします。公式の例の出力は次の形です。

COPY (SELECT * FROM (VALUES(1),(2)) val(id)) TO STDOUT (FORMAT JSON, FORCE_ARRAY);
[
 {"id":1}
,{"id":2}
]

16 では FORMAT json は構文エラーで、行ごとの JSON は row_to_json、配列は json_agg で作ります。

COPY (SELECT row_to_json(d) FROM distributors d) TO STDOUT;
{"did":11,"dname":"Global Electronics"}
SELECT json_agg(d) FROM distributors d;
 [{"did":11,"dname":"Global Electronics"}]

COPY には、ほかに HEADER に行数を書いて複数行の見出しを飛ばす、ON_ERROR set_null で読めない値を NULL にして続ける、パーティション表を COPY TO で直接出す、が加わりました。COPY の基本は関連記事「PostgreSQL CSVインポート｜COPYと\copyの違いとエラー対処」で扱っています。

関数・型の追加（16 でのエラーと代わり）

このほか、encode の base32hex、regdatabase による DB 名と OID の変換、tid_block()・tid_offset()、範囲の引き算で隙間ごとに返す range_minus_multi()、PL/Python のイベントトリガーが加わります。

PostgreSQL 19の性能の変更（NOT IN・I/O・autovacuum・レプリケーション）

この節では、SQL を変えずに速くなる変更と、16 で測った「NOT IN が遅くなる場面」が分かります。

19 のプランナーは、NULL が無いと分かる NOT IN を ANTI JOIN に変換します。16 では NOT IN はサブプランのままで、サブクエリの結果が work_mem に収まらないとハッシュを使えず、1行ごとにサブクエリの結果をなめます。

16 で測った：NOT IN と NOT EXISTS の差

3,000行の表から、30,000行の表に無いものを数えました。両方の列は NOT NULL、work_mem = '64kB' です。

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF, SUMMARY ON)
  SELECT count(*) FROM o2 WHERE customer_id NOT IN (SELECT customer_id FROM b2);
 Aggregate (actual rows=1 loops=1)
   ->  Seq Scan on o2 (actual rows=2572 loops=1)
         Filter: (NOT (SubPlan 1))
         Rows Removed by Filter: 428
         SubPlan 1
           ->  Materialize (actual rows=25751 loops=3000)
                 ->  Seq Scan on b2 (actual rows=30000 loops=1)
 Execution Time: 5099.320 ms

EXPLAIN (ANALYZE, COSTS OFF, TIMING OFF, SUMMARY ON)
  SELECT count(*) FROM o2 WHERE NOT EXISTS (SELECT 1 FROM b2 WHERE b2.customer_id = o2.customer_id);
 Aggregate (actual rows=1 loops=1)
   ->  Hash Right Anti Join (actual rows=2572 loops=1)
         Hash Cond: (b2.customer_id = o2.customer_id)
 Execution Time: 4.706 ms

同じ答え（2,572行）で約1,000倍の差です。19 では NULL が無いと証明できる NOT IN がこの ANTI JOIN の形になります（公式の範囲）。NULL があり得る列では意味が違うため変換されません。16 で NULL が混じると、次のように結果そのものが変わります。

-- a = {1,2,3}、b = {1, NULL}
SELECT count(*) AS not_in FROM a WHERE x NOT IN (SELECT y FROM b);
 not_in
--------
      0
SELECT count(*) AS not_exists FROM a WHERE NOT EXISTS (SELECT 1 FROM b WHERE b.y = a.x);
 not_exists
------------
          2

19 を待たずに効く対策は、NOT IN を NOT EXISTS に書き換えることです。NULL の扱いも直感どおりになります。

そのほかの性能の変更（公式の範囲）

索引の種類の選び方は、関連記事「PostgreSQLインデックスの種類｜B-tree/GIN/GiST/BRIN実測」で扱っています。

PostgreSQL 19で既定値が変わる設定（JIT・ロック・ログ・TOAST圧縮）

この節では、設定ファイルを変えていなくても 19 で動きが変わる既定値と、16 で測ったその影響が分かります。

手元の 16.15 の既定値を SHOW で出し、19 のリリースノートの値と並べました。

JIT：小さな問い合わせでは無いほうが速い

200,000行の集計で、jit_above_cost を下げて JIT を効かせた場合と切った場合を比べました。

JIT:
  Functions: 5
  Options: Inlining false, Optimization false, Expressions true, Deforming true
  Timing: Generation 0.501 ms, Inlining 0.000 ms, Optimization 0.345 ms, Emission 6.618 ms, Total 7.465 ms
Execution Time: 56.247 ms     -- JIT on（新しいセッションの1回目）
Execution Time: 32.465 ms     -- JIT on（2回目）
Execution Time: 33.293 ms     -- JIT off

この規模では JIT は速くならず、1回目はコンパイルと読み込みの分だけ遅くなりました（サーバー起動直後の最初の1回は 11,468ms かかりました）。19 で既定が off になる理由として、公式は「JIT を使うかのコストの見積もりが当てにならないと分かった」と書いています。大きな分析の問い合わせが多い所は、19 で jit = on を設定し直すかを測って決めます。

max_locks_per_transaction：16 で出した out of shared memory

1つのトランザクションで表を4,000個作り、ロックの表があふれる所を探しました（max_connections = 10）。

BEGIN;
DO $$ BEGIN FOR i IN 1..4000 LOOP EXECUTE format('CREATE TABLE lk_%s (id int)', i); END LOOP; END $$;
ERROR:  out of shared memory
HINT:  You might need to increase max_locks_per_transaction.
CONTEXT:  SQL statement "CREATE TABLE lk_1710 (id int)"

64 では1,710個目、128 に上げると3,349個目で同じエラーになりました。19 ではロックの領域の割り当て方が変わり、リリースノートは「以前と同じ容量にするには値を倍にする」と書いています。既定の 64 → 128 はこの調整で、18 以前で 256 のように明示していた所は 19 では 512 にする計算です。パーティションの多い表を1つの文で触る所で効きます。

log_lock_waits：19 では既定でこの行が出る

16 でセッションの中だけ log_lock_waits = on・deadlock_timeout = '200ms' にして、ロック待ちを起こしました。

LOG:  process 5616 still waiting for AccessShareLock on relation 16424 of database 16384 after 200.082 ms at character 22
DETAIL:  Process holding the lock: 5614. Wait queue: 5616.
STATEMENT:  SELECT count(*) FROM logs
LOG:  process 5616 acquired AccessShareLock on relation 16424 of database 16384 after 1497.053 ms at character 22

19 ではこの行が既定で出るので、ログの量やログ監視の通知の条件を見直します。ロック待ちの調べ方は、関連記事「PostgreSQLロック確認SQL｜ブロッキング特定から解除までコピペ集」で扱っています。

TOAST の lz4：既存のデータは pglz のまま

同じ2,000件の長い文字列（平均17,899バイト）を、列ごとに圧縮方式を指定した表へ入れて比べました。

大事なのは次の結果です。pglz の表から INSERT ... SELECT で lz4 の列へ写し、さらに VACUUM FULL をかけても、ほとんどの値は pglz のままでした。

INSERT INTO doc_lz4 SELECT * FROM doc_pglz;
VACUUM FULL doc_lz4;
SELECT pg_column_compression(body), count(*) FROM doc_lz4 GROUP BY 1;
 pg_column_compression | count
-----------------------+-------
 lz4                   |    16
 pglz                  |  1984

圧縮済みの値はそのまま写されるためです。19 に上げても既存の値は pglz のままで、lz4 になるのは新しく書いた値からです。pg_column_compression() で割合を確かめられます。

18からの移行で壊れる点（PostgreSQL 19の非互換17項目）

この節では、リリースノートの「Migration to Version 19」の17項目と、16 で再現したダンプの落とし穴が分かります。

19 へはどの版からでも、pg_dumpall でのダンプと復元、pg_upgrade、論理レプリケーションのどれかで移します。そのうえで次の非互換を確かめます。

表の1番目の設定の名前は password_expiration_warning_threshold、2番目は md5_password_warnings です。

16 で再現した：standard_conforming_strings = off のダンプ

DB の設定を standard_conforming_strings = off にして、バックスラッシュを含む値（C:\Users\rjc）を pg_dump 16.15 で出しました。

14:SET standard_conforming_strings = off;
41:INSERT INTO public.paths VALUES ('C:\\Users\\rjc');

off のダンプは、バックスラッシュを2つ重ねて書き、先頭の SET で「off として読む」前提にしています。19 のサーバーは常に on なので、リリースノートは「正しく読み込めない」と書いています。SET が効かない状態を 16 で作る（SET の行を外して on のまま読み込む）と、値が変わりました。

       p        | length
----------------+--------
 C:\\Users\\rjc |     14      -- 読み込んだ先（on のまま）
      p       | length
--------------+--------
 C:\Users\rjc |     12      -- 元の値

エラーにならずに値だけが変わるのがこの変更の怖い所です。対策は、19 の pg_dump・pg_dumpall でダンプを取るか、ダンプを取る前に on に戻すことです（on で取ったダンプでは、16.15 でも 'C:\Users\rjc' のまま出ました）。

16 で確かめた：0行の JSON_ARRAY は NULL

SELECT JSON_ARRAY(SELECT price FROM quotes WHERE price > 1000) IS NULL AS is_null_on_16;
 is_null_on_16
---------------
 t
SELECT COALESCE(JSON_ARRAY(SELECT price FROM quotes WHERE price > 1000), '[]') AS same_on_16_and_19;
 same_on_16_and_19
-------------------
 []

19 では空の配列 [] が返るので、IS NULL で「0件」を判定している所は動きが変わります。COALESCE で [] にそろえておくと、16〜18 と 19 で同じ結果になります。

pg_upgradeで19に上げる前の確認SQLと手順

この節では、19 の pg_upgrade が拒否する条件を今のクラスタで探す SQL と、見つかったときの直し方の実物が分かります。

19 の pg_upgrade は、btree_gist の inet/cidr 索引と、改行を含む名前があるクラスタの移行を拒否します。16 のクラスタにわざと両方を作り、探す SQL を流しました。

-- 1) btree_gist の inet/cidr 索引
SELECT n.nspname, c.relname AS index_name, opc.opcname
FROM pg_index i
JOIN pg_class c ON c.oid = i.indexrelid
JOIN pg_namespace n ON n.oid = c.relnamespace
JOIN pg_opclass opc ON opc.oid = ANY (i.indclass::oid[])
WHERE opc.opcname IN ('gist_inet_ops', 'gist_cidr_ops');

-- 2) 改行・復帰を含む名前
SELECT 'role' AS kind, rolname AS name FROM pg_roles WHERE rolname ~ E'[\\r\\n]'
UNION ALL SELECT 'database', datname FROM pg_database WHERE datname ~ E'[\\r\\n]'
UNION ALL SELECT 'tablespace', spcname FROM pg_tablespace WHERE spcname ~ E'[\\r\\n]';

-- 3) MULE_INTERNAL の DB　4) MD5 のパスワード　5) RADIUS の行
SELECT datname FROM pg_database WHERE pg_encoding_to_char(encoding) = 'MULE_INTERNAL';
SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';
SELECT line_number, type, auth_method FROM pg_hba_file_rules WHERE auth_method = 'radius';

-- 6) standard_conforming_strings = off の設定
SELECT coalesce(d.datname,'(all)') AS db, s.setconfig FROM pg_db_role_setting s
LEFT JOIN pg_database d ON d.oid = s.setdatabase
WHERE array_to_string(s.setconfig, ',') ILIKE '%standard_conforming_strings=off%';

 nspname |     index_name     |    opcname
---------+--------------------+---------------
 public  | access_log_ip_gist | gist_inet_ops
(1 row)

 kind | name
------+------
 role | app +
      | user
(1 row)

 rolname
---------
 legacy          -- 4) MD5
(1 row)

   db   |             setconfig
--------+-----------------------------------
 t291db | {standard_conforming_strings=off}
(1 row)

btree_gist を入れた DB で USING gist (ip) と書くと、btree_gist の gist_inet_ops が既定で選ばれていました。リリースノートは、この演算子クラスは「返すべき行を除外することがあり壊れている」と書いています。直したあとの状態です。

DROP INDEX access_log_ip_gist;           -- 本体の inet_ops の索引は別にある
ALTER ROLE "app
user" RENAME TO app_user;
SET password_encryption = 'scram-sha-256';
ALTER ROLE legacy PASSWORD '********';

      relname       | opcname
--------------------+----------
 access_log_ip_core | inet_ops
 rolname  |      head
----------+----------------
 legacy   | SCRAM-SHA-256$

EXPLAIN (COSTS OFF) SELECT * FROM access_log WHERE ip << '10.0.3.0/24';
 Bitmap Heap Scan on access_log
   Recheck Cond: (ip << '10.0.3.0/24'::inet)
   ->  Bitmap Index Scan on access_log_ip_core

本体の GiST の演算子クラスは USING gist (ip inet_ops) と明示して作ります。作り直した索引で、サブネットの検索に索引が使われました。

pg_upgrade の手順

手順3の出力の形を、16.15 から 16.15 への --check で確かめました（19 の pg_upgrade は、上の新しい確認の行が加わります）。

pg_upgrade --check -b /usr/lib/postgresql/16/bin -B /usr/lib/postgresql/16/bin \
  -d /dev/shm/t291/pg/data -D /dev/shm/t291/pg/new -p 54291 -P 54292 -U postgres

Performing Consistency Checks on Old Live Server
------------------------------------------------
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 not-null constraint inconsistencies              ok
Checking for presence of required libraries                   ok
Checking database user is the install user                    ok
Checking for prepared transactions                            ok
Checking for new cluster tablespace directories               ok

*Clusters are compatible*

19 の pg_upgrade では、PGDATA の中に置いた表領域を扱えるようになり、ラージオブジェクトのメタデータの写しも速くなります（公式の範囲）。

PostgreSQL 19でよくあるエラー・つまずき

この節では、19 の機能を試すとき・19 に上げたときに出やすいメッセージと直し方が分かります。

接続数の上限まわりは、関連記事「PostgreSQL too many clientsの直し方｜接続数と接続プール」で扱っています。

判断表：PostgreSQL 19にいつ上げるか

この節では、今の版ごとに 19 へ上げる時期と、先にやることが分かります。

1. 1いま 14 → 11月12日でサポート終了。19 を待たず 18 へ19.0 の公開は終了日の後。18 なら2030年11月までサポート
2. 2いま 15〜17 → 確認SQLを流し、19.1 前後で計画15 は2027年11月、16 は2028年11月、17 は2029年11月まで
3. 3いま 18 → 急がない。REPACK・WAIT が要る所から非互換17項目を検証環境で確かめる
4. 4新しく作るシステム → 正式版の公開後に 19 で始めるRC はテスト用。マネージドサービスは各社の提供開始を待つ

PostgreSQL 19に関するよくある質問

この節では、PostgreSQL 19 についてよく聞かれることに短く答えます。

Q. PostgreSQL 19 の正式版はいつ出ますか？

A. 公式の予定は2026年11月19日です。RC 1 の発表に「問題で延期や追加の RC が要る場合を除く」とあり、11月12日に RC 2 が出る予定です。

Q. RC 1 を本番で使えますか？

A. 公式は RC を「初版とほぼ同じだが、正式版までに修正が入る可能性がある」と説明しています。本番は正式版を使い、RC は検証環境での確認に使う位置づけです。

Q. RC 1 から正式版へは pg_upgrade が要りますか？

A. RC 1 の発表は、以前の版から RC 1 へ上げるにはメジャーバージョンの移行（pg_upgrade か pg_dump/pg_restore）が要ると書いています。RC から正式版への扱いは、正式版のリリースノートで確かめます。

Q. REPACK があれば拡張の pg_repack は要りませんか？

A. 19 では REPACK (CONCURRENTLY) が標準の機能として使えます。主キーか索引の REPLICA IDENTITY が要る、パーティション親や UNLOGGED の表には使えないなどの条件があるので、表ごとに確かめてから切り替えます。

Q. VACUUM FULL や CLUSTER は使えなくなりますか？

A. 使えます。リリースノートは「互換のために残る」と書いています。

Q. 14 から 19 へ直接上げられますか？

A. pg_upgrade・pg_dumpall はどの以前の版からでも使えます。ただし 14 は2026年11月12日でサポートが終わり、19.0 の予定日はその後です。終了日までに上げるなら 18 が対象になります。

Q. SQL/PGQ（GRAPH_TABLE）は 19 で使えますか？

A. Beta 1 の発表には載っていましたが、RC 1 のリリースノートには載っておらず、公式 wiki の関連項目には「reverted」の印があります。

Q. 19 で JIT が off になると遅くなりますか？

A. 手元の 16 の測定では、20万行の集計で JIT ありとなしはほぼ同じで、1回目は JIT のほうが遅くなりました。JIT が効くのは大きな分析の問い合わせで、そうした問い合わせが多い所は jit = on と比べて決めます。

Q. lz4 に変わると既存のデータも小さくなりますか？

A. なりません。手元の 16 では、INSERT ... SELECT で写しても VACUUM FULL をかけても、圧縮済みの値は pglz のままでした。lz4 になるのは新しく書いた値からです。

Q. 19 を手元で試すには？

A. postgresql.org/download の各 OS 向けパッケージ（Linux は PGDG のリポジトリ）か、ソースから入れます。2026年11月5日時点で、npm・PyPI の埋め込み用の配布物は 18.6 までで、19 はありませんでした。

まとめ

この節では、記事の要点を5つにまとめます。

• 2026年11月5日時点の最新は 19 RC 1（10月15日）。RC 2 は11月12日、正式版は11月19日の予定です。
• 主な新機能は REPACK (CONCURRENTLY)・WAIT FOR LSN・ON CONFLICT DO SELECT・IGNORE NULLS・COPY の JSON 出力・並列 autovacuum。SQL/PGQ・FOR PORTION OF は RC 1 のリリースノートにありません。
• 16 で測った差：VACUUM FULL の間は SELECT も3.3秒待ち、NULL の無い NOT IN は NOT EXISTS の約1,000倍遅い場面がありました。19 はこの2つを直す機能を持ちます。
• 既定値の変更：jit が off、max_locks_per_transaction が 128（容量は同じ）、log_lock_waits が on、TOAST が lz4（既存の値は pglz のまま）。
• 上げる前に、btree_gist の inet 索引・改行を含む名前・MD5・RADIUS・standard_conforming_strings = off を確認SQLで探して直します。

参考・出典

この節では、記事を書くときに確かめた公式の資料を挙げます（確認日はすべて2026年11月5日）。

• PostgreSQL「PostgreSQL 19 RC 1 Released!」（2026年10月15日）：https://www.postgresql.org/about/news/postgresql-19-rc-1-released-3409/
• PostgreSQL「PostgreSQL 19 Beta 1 Released!」（2026年6月4日）：https://www.postgresql.org/about/news/postgresql-19-beta-1-released-3313/
• PostgreSQL 19 Documentation「E.1. Release 19」（RC 1、AS OF 2026-10-09）：https://www.postgresql.org/docs/19/release-19.html
• PostgreSQL 19 Documentation「REPACK」：https://www.postgresql.org/docs/19/sql-repack.html
• PostgreSQL 19 Documentation「WAIT」：https://www.postgresql.org/docs/19/sql-wait.html
• PostgreSQL 19 Documentation「INSERT」：https://www.postgresql.org/docs/19/sql-insert.html
• PostgreSQL 19 Documentation「COPY」：https://www.postgresql.org/docs/19/sql-copy.html
• PostgreSQL 19 Documentation「Window Functions」：https://www.postgresql.org/docs/19/functions-window.html
• PostgreSQL 19 Documentation「pg_plan_advice」：https://www.postgresql.org/docs/19/pgplanadvice.html
• PostgreSQL 19 Documentation「Upgrading a PostgreSQL Cluster」：https://www.postgresql.org/docs/19/upgrading.html
• PostgreSQL「Versioning Policy」：https://www.postgresql.org/support/versioning/
• PostgreSQL Wiki「PostgreSQL 19 Open Items」：https://wiki.postgresql.org/wiki/PostgreSQL_19_Open_Items
• PostgreSQL 19 Documentation「pg_upgrade」：https://www.postgresql.org/docs/19/pgupgrade.html

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。