diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml
new file mode 100644
index 63af1a5..89723c3
*** a/doc/src/sgml/logical-replication.sgml
--- b/doc/src/sgml/logical-replication.sgml
***************
*** 95,110 ****
      how the table is accessed. Each table can be added to multiple
      publications if needed.  Publications may currently only contain
      tables. Objects must be added explicitly, except when a publication
!     is created for <literal>ALL TABLES</>. There is no default name for
!     a publication which specifies all tables.
    </para>
    <para>
      Publications can choose to limit the changes they produce to show
      any combination of <command>INSERT</>, <command>UPDATE</> and
      <command>DELETE</> in a similar way to the way triggers are fired by
!     particular event types. Only tables with a <literal>REPLICA IDENTITY</>
!     index can be added to a publication which replicates <command>UPDATE</>
!     and <command>DELETE</> operation.
    </para>
    <para>
      The definition of a publication object will be included within
--- 95,110 ----
      how the table is accessed. Each table can be added to multiple
      publications if needed.  Publications may currently only contain
      tables. Objects must be added explicitly, except when a publication
!     is created for <literal>ALL TABLES</>.
    </para>
    <para>
      Publications can choose to limit the changes they produce to show
      any combination of <command>INSERT</>, <command>UPDATE</> and
      <command>DELETE</> in a similar way to the way triggers are fired by
!     particular event types. If a table with without a <literal>REPLICA IDENTITY</>
!     index is added to a publication which replicates <command>UPDATE</> or
!     <command>DELETE</> operations then subsequent <command>UPDATE</>
!     or <command>DELETE</> operations will fail on the publisher.
    </para>
    <para>
      The definition of a publication object will be included within
***************
*** 195,214 ****
    </para>
    <para>
      A conflict will produce an error and will stop the replication; it
!     must be resolved manually by the user.
    </para>
    <para>
!     The resolution can be done either by changing data on the subscriber
!     so that it does not conflict with incoming change or by skipping the
!     transaction that conflicts with the existing data. The transaction
!     can be skipped by calling the
!     <link linkend="pg-replication-origin-advance">
!     <function>pg_replication_origin_advance()</function></link> function
!     with a <literal>node_name</> corresponding to the subscription name. 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.
!   </para>
  </sect1>
  <sect1 id="logical-replication-architecture">
    <title>Architecture</title>
--- 195,206 ----
    </para>
    <para>
      A conflict will produce an error and will stop the replication; it
!     must be resolved manually by the user. Details about the conflict can
!     be found in the subscribers PostgreSQL log.
    </para>
    <para>
!     The resolution can only be accomplished by manualy changing the
!     subscriber so that it does not conflict with incoming change.
  </sect1>
  <sect1 id="logical-replication-architecture">
    <title>Architecture</title>
***************
*** 229,237 ****
      loads the standard logical decoding plugin (pgoutput). 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 publication specification. The data are then continuously
      transferred using the streaming replication protocol to the Apply worker
!     which maps them to the local tables and applies the individual changes as
      they are received in exact transactional order.
    </para>
    <para>
--- 221,229 ----
      loads the standard logical decoding plugin (pgoutput). 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 publication specification. The data is then continuously
      transferred using the streaming replication protocol to the Apply worker
!     which maps the data to local tables and applies the individual changes as
      they are received in exact transactional order.
    </para>
    <para>