The database schema and DDL commands are not replicated. The initial schema can be copied by hand using <literal>pg_dump &#45;-schema-only</literal>. Subsequent schema changes would need to be kept in sync manually. (Note, however, that there is no need for the schemas to be absolutely the same on both sides.) Logical replication is robust when schema definitions change in a live database: When the schema is changed on the publisher and replicated data starts arriving at the subscriber but does not fit into the table schema, replication will error until the schema is updated. In many cases, intermittent errors can be avoided by applying additive schema changes to the subscriber first. データベーススキーマおよびDDLコマンドはレプリケーションされません。 初期スキーマは、pg_dump --schema-onlyを使ってコピーすることができます。 以後のスキーマ変更の同期は手動で行ないます。 （なお、両者でスキーマは完全に同じである必要はないことに留意してください。） 稼働中のスキーマ定義変更に対して、論理レプリケーションは頑健です。 スキーマがパブリッシャー側で変更され、レプリケーションデータがサブスクライバー側に到着し始めたものの、データがテーブルスキーマに合致しない場合は、スキーマが変更されるまではレプリケーションはエラーとなります。 多くの場合、間欠的なエラーは、サブスクライバーに先に追加的なスキーマ変更を行うことで避けることができます。

Sequence data is not replicated. The data in serial or identity columns backed by sequences will of course be replicated as part of the table, but the sequence itself would still show the start value on the subscriber. If the subscriber is used as a read-only database, then this should typically not be a problem. If, however, some kind of switchover or failover to the subscriber database is intended, then the sequences would need to be updated to the latest values, either by copying the current data from the publisher (perhaps using <command>pg_dump</command>) or by determining a sufficiently high value from the tables themselves. シーケンスデータはレプリケーションされません。 シーケンスによって裏付けされたSERIAL型や識別列のデータは、もちろんテーブルの一部としてレプリケーションされます。 しかし、シーケンス自体は、サブスクライバーがスタートした時の値のままです。 サブスクライバーが読み取り専用のデータベースとして使われているなら、通常は問題になりません。 しかし、サブスクライバーのデータベースをスイッチオーバーやフェイルオーバーするつもりなら、パブリッシャーから現在のデータをコピーするか（おそらくpg_dumpを使います）、テーブル自身から十分に大きな値を決定し、シーケンスを最新の値に更新しなければなりません。

Replication of <command>TRUNCATE</command> commands is supported, but some care must be taken when truncating groups of tables connected by foreign keys. When replicating a truncate action, the subscriber will truncate the same group of tables that was truncated on the publisher, either explicitly specified or implicitly collected via <literal>CASCADE</literal>, minus tables that are not part of the subscription. This will work correctly if all affected tables are part of the same subscription. But if some tables to be truncated on the subscriber have foreign-key links to tables that are not part of the same (or any) subscription, then the application of the truncate action on the subscriber will fail. TRUNCATEコマンドのレプリケーションはサポートされますが、外部キーで結びついたテーブル群を削除する場合には注意が必要です。 削除処理をレプリケーションするとき、サブスクライバーはパブリッシャーで明示的に指定され削除された、もしくはCASCADEにより暗黙的に削除されたテーブル群から、サブスクリプションの一部ではないテーブルを除いたテーブル群を削除します。 この処理は、外部キーで関連付けられた全てのテーブルが同一のサブスクリプションの一部であれば、正常に動作します。 しかし、サブスクライバーで削除されるテーブルが同一のサブスクリプションの一部でないテーブルと外部キーで接続されていた場合、サブスクライバー上の削除処理は失敗します。

Large objects (see <xref linkend="largeobjects"/>) are not replicated. There is no workaround for that, other than storing data in normal tables. ラージオブジェクト（第33章参照）はレプリケーションされません。 通常のテーブルにデータを格納する以外に回避方法はありません。

Replication is only supported by tables, including partitioned tables. Attempts to replicate other types of relations, such as views, materialized views, or foreign tables, will result in an error. レプリケーションは、パーティション化テーブルを含むテーブルでのみサポートされています。 ビュー、マテリアライズドビュー、外部テーブルのような、その他の種類のリレーションをレプリケーションしようとすると、エラーになります。

When replicating between partitioned tables, the actual replication originates, by default, from the leaf partitions on the publisher, so partitions on the publisher must also exist on the subscriber as valid target tables. (They could either be leaf partitions themselves, or they could be further subpartitioned, or they could even be independent tables.) Publications can also specify that changes are to be replicated using the identity and schema of the partitioned root table instead of that of the individual leaf partitions in which the changes actually originate (see <link linkend="sql-createpublication-params-with-publish-via-partition-root"><literal>publish_via_partition_root</literal></link> parameter of <command>CREATE PUBLICATION</command>). パーティション化テーブル間でレプリケーションする場合には、実際のレプリケーションは、デフォルトでは、パブリッシャー側の末端のパーティションから開始します。ですので、パブリッシャー側のパーティションがサブスクライバー側にも有効な対象テーブルとして存在していなければなりません。 (対象テーブルは、それ自身が末端のパーティションかもしれませんし、さらにサブパーティション化されているかもしれません。独立したテーブルであっても構いません。) パブリケーションは、変更が実際に開始された個々の末端のパーティションのIDとスキーマの代わりに、パーティション化されたルートのテーブルのIDとスキーマを使って指定することもできます(CREATE PUBLICATIONのpublish_via_partition_rootパラメータを参照してください)。

When using <link linkend="sql-altertable-replica-identity-full"><literal>REPLICA IDENTITY FULL</literal></link> on published tables, it is important to note that the <literal>UPDATE</literal> and <literal>DELETE</literal> operations cannot be applied to subscribers if the tables include attributes with datatypes (such as point or box) that do not have a default operator class for B-tree or Hash. However, this limitation can be overcome by ensuring that the table has a primary key or replica identity defined for it. パブリッシュされたテーブルでREPLICA IDENTITY FULLを使用する場合、テーブルにBツリーまたはハッシュのデフォルトの演算子クラスを持たないデータ型(pointやboxなど)の属性が含まれていると、UPDATEおよびDELETE操作をサブスクライバに適用できないことに注意してください。 ただし、この制限は、テーブルに主キーまたはレプリカアイデンティティを定義することで回避できます。