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.
    </para>
   </listitem>

   <listitem>
    <para>
     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.
    </para>
   </listitem>

   <listitem>
    <para>
     Large objects (see <xref linkend="largeobjects"/>) are not replicated.
     There is no workaround for that, other than storing data in normal
     tables.
    </para>
   </listitem>

   <listitem>
    <para>
     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.
    </para>
   </listitem>

   <listitem>
    <para>
     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>).
    </para>
   </listitem>

   <listitem>
    <para>
     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.
    </para>
   </listitem>
  </itemizedlist>
 </sect1>

 <sect1 id="logical-replication-architecture">
  <title>Architecture</title>

  <para>
   Logical replication is built with an architecture similar to physical
   streaming replication (see <xref linkend="streaming-replication"/>).  It is
   implemented by <literal>walsender</literal> and <literal>apply</literal>
   processes.  The walsender process starts logical decoding (described
   in <xref linkend="logicaldecoding"/>) of the WAL and loads the standard
   logical decoding output plugin (<literal>pgoutput</literal>).  The plugin
   transforms the changes read
   from WAL to the logical replication protocol
   (see <xref linkend="protocol-logical-replication"/>) and filters the data
   according to the publication specification.