the finish LSN (i.e., 0/14C0379).  The current position of
   origins can be seen in the <link linkend="view-pg-replication-origin-status">
   <structname>pg_replication_origin_status</structname></link> system view.
   Please note that skipping the whole transaction includes skipping changes that
   might not violate any constraint.  This can easily make the subscriber
   inconsistent.
   The additional details regarding conflicting rows, such as their origin and
   commit timestamp can be seen in the <literal>DETAIL</literal> line of the
   log. But note that this information is only available when
   <link linkend="guc-track-commit-timestamp"><varname>track_commit_timestamp</varname></link>
   is enabled on the subscriber. Users can use this information to decide
   whether to retain the local change or adopt the remote alteration. For
   instance, the <literal>DETAIL</literal> line in the above log indicates that
   the existing row was modified locally. Users can manually perform a
   remote-change-win.
  </para>

  <para>
   When the
   <link linkend="sql-createsubscription-params-with-streaming"><literal>streaming</literal></link>
   mode is <literal>parallel</literal>, the finish LSN of failed transactions
   may not be logged. In that case, it may be necessary to change the streaming
   mode to <literal>on</literal> or <literal>off</literal> and cause the same
   conflicts again so the finish LSN of the failed transaction will be written
   to the server log. For the usage of finish LSN, please refer to <link
   linkend="sql-altersubscription"><command>ALTER SUBSCRIPTION ...
   SKIP</command></link>.
  </para>
 </sect1>

 <sect1 id="logical-replication-restrictions">
  <title>Restrictions</title>

  <para>
   Logical replication currently has the following restrictions or missing
   functionality.  These might be addressed in future releases.
  </para>

  <itemizedlist>
   <listitem>
    <para>
     The database schema and DDL commands are not replicated.  The initial
     schema can be copied by hand using <literal>pg_dump
     --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.
    </para>
   </listitem>

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