PostgreSQL 18とその後:技術者Blog
PostgreSQLインサイド

Amit Kapila

FUJITSU Limited
Software Open Innovation Business Unit Data Management Division
Senior Director

私はニューヨークで開催された「PGConf NYC 2025」に参加し、PostgreSQLの論理レプリケーションの今後の方向性について発表しました。本記事では、論理レプリケーションの進化と、PostgreSQL 18で導入された論理レプリケーションの機能強化についてご紹介します。

PostgreSQLの進化 - 論理レプリケーションの発展

PostgreSQLの論理レプリケーションは、初期の論理デコーディングの登場から継続的な機能強化を経て、データベースの基本機能の一つとして成長してきました。現在では、高可用性、スケーラビリティ、さらには異なるデータベースシステムとの連携など、多岐にわたるユースケースに対応できる強力なツールとなっています。

PostgreSQLの進化 - 論理レプリケーションの発展

PostgreSQL 18の機能強化と新機能

PostgreSQL 18では、論理レプリケーションに多くの改善が加えられました。変更に関するすべての機能一覧は、PostgreSQLオフィシャルドキュメントの「PostgreSQL: Documentation: 18: E.1. Release 18」でご確認いただけます。

それでは、PostgreSQL 18のいくつかの機能強化についてご紹介しましょう。

コンフリクト検出とロギング

PostgreSQL 18では、新しい種類のコンフリクト検出が導入され、コンフリクト情報の管理が大幅に改善されました。

新しいコンフリクトの種類

  • INSERT_EXISTS または UPDATE_EXISTS (重複行の挿入または更新)
    NOT DEFERRABLEな一意性制約に違反する行を挿入または更新しようとした場合に発生します。

  • UPDATE_ORIGIN_DIFFERS または DELETE_ORIGIN_DIFFERS (更新/削除元の相違)
    以前に別のオリジン(発生元)によって変更された行を更新または削除しようとした場合に発生します。

  • UPDATE_MISSING または DELETE_MISSING (更新/削除対象行の不一致)
    更新または削除しようとしたタプル(行)が見つからなかった場合に発生します。

  • MULTIPLE_UNIQUE_CONFLICTS (複数の一意性コンフリクト)
    複数のNOT DEFERRABLEな一意性制約に違反する行を挿入または更新しようとした場合に発生します。

並列処理の有効化

PostgreSQL 18では、大規模トランザクションの論理レプリケーションを高速かつ効率的に行うため、並列処理がデフォルトの動作となりました。
従来、論理レプリケーションにおいて、サブスクライバーはパブリッシャーのトランザクションがコミットされるまで待機する必要がありましたが、並列処理が有効化されることで、コミットを待たずに即座に処理を開始できます。これにより、レプリケーションの遅延が最小限に抑えられ、より高いスループットが期待できます。

設定方法

サブスクリプションパラメータ「streaming」に「parallel」を設定します。これはPostgreSQL 18からのデフォルト値です。

postgres=# CREATE SUBSCRIPTION sub CONNECTION 'dbname=postgres' PUBLICATION pub WITH (streaming = parallel);
NOTICE: created replication slot "sub" on publisher
CREATE SUBSCRIPTION
postgres=# SELECT subname, substream FROM pg_subscription;
 subname | substream
---------+-----------
 sub     | p
(1 row)

並列度は、サブスクリプションパラメータ「max_parallel_apply_workers_per_subscription」によって調整できます。

max_parallel_apply_workers_per_subscription = 5

pg_createsubscriberの機能強化

運用の利便性を高めるため、pg_createsubscriberツールにいくつかの機能が改善されました。レプリケーションワークフローを簡素化する主な改善点については、以下のブログ記事(英語)で解説しています。

PostgreSQL 19とその後

最後に、コミュニティで活発に行われている議論の1つを紹介して、この記事を締めくくりたいと思います。なお、ここで紹介する機能が次のリリースまたは将来のリリースに必ず提供されるものではないことご承知おきください。

コンフリクト履歴の閲覧

これまでの論理レプリケーションでは、データコンフリクトが発生した場合、その情報は主にデータベースのログファイルに記録されるのみでした。ログファイルは継続的に大量に出力されるため、特定のコンフリクト情報を効率的に検索・分析することは非常に困難であり、特に複雑なレプリケーション設定や多数のコンフリクトが発生する環境では、問題の特定とデバッグに多くの時間と労力を要していました。
コンフリクトに関する重要な情報を構造化された形でデータベース内の専用テーブルに格納することができるようになると、コンフリクトの分析と管理が容易になります。コンフリクトが発生した際、以下の詳細情報が新しいテーブルに記録されます。

  • テーブル名とタプル(行)の詳細

  • コンフリクトの種類

  • リモートのトランザクションID(XID)、ログシーケンス番号(LSN)、およびコミットタイムスタンプ

  • ローカルのトランザクションID(XID)、ログシーケンス番号(LSN)、およびコミットタイムスタンプ

  • オリジン(発生元)に関する情報

この機能を利用するためには、サブスクリプションの作成時または変更時に、特定の新しいオプションを追加して、コンフリクト履歴を格納するテーブルを指定します。

postgres=# CREATE SUBSCRIPTION sub CONNECTION 'dbname=postgres port=5432' PUBLICATION pub WITH (conflict_log_table=myschema.my_conflict_table);

これにより、ユーザーは標準のSQLクエリを使ってコンフリクト履歴を簡単に参照、集計、分析できるようになり、レプリケーションの健全性を監視し、問題解決を効率的に行うことが可能になります。

  • ログでコンフリクトを報告

  • LOG:  conflict detected on relation "public.test": conflict=update_origin_differs
    
    DETAIL: Updating the row that was modified locally in transaction 776 at 2025-09-22 17:14:48.106542+05:30.
            Existing local row (1, 10); remote row (1, 20); replica identity (a)=(1).
    
    CONTEXT: processing remote data for replication origin "pg_16391" during message type "UPDATE" for replication target relation "public.test" in transaction 770, finished at 0/01766E48
  • コンフリクトの詳細がテーブルに保存

  • postgres-# select * from myschema.my_conflict_table;
    -[ RECORD 1 ]-----+---------------------------------
    relid             | 16385
    local_xid         | 776
    remote_xid        | 770
    local_lsn         | 0/00000000
    remote_commit_lsn | 0/01766E48
    local_commit_ts   | 2025-09-22 17:14:48.106542+05:30
    remote_commit_ts  | 2025-09-22 17:14:53.090079+05:30
    table_schema      | public
    table_name        | test
    conflict_type     | update_origin_differs
    local_origin      |
    remote_origin     | pg_16391
    key_tuple         | {"a":1,"b":20}
    local_tuple       | {"a":1,"b":10}
    remote_tuple      | {"a":1,"b":20}

最後に

PostgreSQL 18における論理レプリケーションの機能強化は、データベース管理と運用において計り知れない価値をもたらします。特にコンフリクト検出とロギングの改善は、複雑なレプリケーション完了での問題特定とデバッグを大幅に効率化し、システムの安定性と信頼性向上に貢献するでしょう。
PostgreSQLは今後も進化を続け、より多様なビジネスニーズに対応していくことと期待しています。富士通はこらからも、PostgreSQLコミュニティへの貢献、そしてFujitsu Enterprise Postgresを通じたお客様のビジネス成長を支援してまいります。

本記事が、皆さまのPostgreSQL活用の一助となれば幸いです。今後もPostgreSQLの進化にご期待いただくとともに、我々の技術者ブログにご注目ください。

関連リンク

PGConf NYC 2025での講演内容については、以下をご覧ください。

参考

富士通のウェブサイト「PostgreSQLインサイド」では、富士通の技術者による最新動向を紹介するブログや、PostgreSQLを利用するうえで知っておきたい技術情報・豆知識、およびFujitsu Enterprise Postgresに関する記事を掲載しています。

Fujitsu Enterprise Postgres(エンタープライズ ポストグレス)は、OSS(オープン・ソース・ソフトウェア)のPostgreSQLをエンジンとし、富士通のデータベース技術とノウハウで導入・運用のしやすさを向上し、「セキュリティ」「性能」「信頼性」を強化したデータベースです。
Fujitsu Enterprise Postgresの製品サイト」では、製品の概要、無料体験版、サービス、技術資料、お客様の導入事例に関する情報を掲載しています。

2025年10月20日公開

富士通のソフトウェア公式チャンネル(YouTube)

本コンテンツに関するお問い合わせ

Webでのお問い合わせ

当社はセキュリティ保護の観点からSSL技術を使用しております。

ページの先頭へ