★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

30.1. パブリケーション

パブリケーションは、どのような物理レプリケーションのマスターにも定義できます。 パブリケーションが定義されたノードは、パブリッシャーと呼ばれます。 パブリケーションは、テーブルか、テーブルのグループから生成された更新の集合であると同時に、更新セットあるいはレプリケーションセットであるとも言えます。 一つのパブリケーションは一つのデータベースにのみ存在します。

パブリケーションはスキーマとは異なり、テーブルがどのようにアクセスされるかには影響しません。 必要ならば、テーブルを複数のパブリケーションに追加できます。 今のところパブリケーションはテーブルのみを含むことができます。 パブリケーションがALL TABLESで作られた場合を除き、オブジェクトは明示的に追加されなければなりません。

パブリケーションは、生成される更新を、INSERTUPDATEDELETETRUNCATEのうちのどのような組み合わせにも制限することができます。 これはトリガーが特定のイベント型によって起動されることに似ています。 デフォルトでは、すべての操作タイプがレプリケーションされます。

パブリッシュされたテーブルは、UPDATEDELETEをレプリケーションできるようにするために、レプリカアイデンティティの設定を含んでいなければなりません。 そうすることにより、サブスクライバー側で更新または削除する対象の正しい行が特定できるようになります。 デフォルトでは主キーがあれば、それがレプリカアイデンティティになります。 他に、ユニークキー(追加の要件を伴います)もレプリカアイデンティティにできます。 テーブルに適当なキーがなければ、レプリカアイデンティティをfullにできます。 これは、行全体がキーになることを意味します。 しかし、これは非常に非効率なので、他の解決方法がない場合のみの代替手段にすべきです。 full以外のレプリカアイデンティティがパブリッシャー側に設定されている場合、同じか、より少ない列を含むレプリカアイデンティティがサブスクライバー側に設定されていなければなりません。 レプリカアイデンティティを設定する詳細な方法については、REPLICA IDENTITYをご覧ください。 UPDATEあるいはDELETE操作をレプリケーションするパブリケーションに、レプリカアイデンティティがないテーブルが追加されると、以後UPDATEあるいはDELETE操作が行われるとパブリッシャー側でエラーが発生します。 INSERT操作は、レプリカアイデンティティの設定に関わらず実行されます。

すべてのパブリケーションは、複数のサブスクライバーを持つことができます。

パブリケーションは、CREATE PUBLICATIONコマンドで作成し、対応するコマンドで変更や削除ができます。

個々のテーブルはALTER PUBLICATIONで動的に追加削除できます。 ADD TABLEおよびDROP TABLE操作はトランザクションの対象です。 ひとたびトランザクションがコミットされれば、正しいスナップショットでテーブルのレプリケーションが開始あるいは終了されます。