Updating a row that was previously modified by another origin.
       Note that this conflict can only be detected when
       <link linkend="guc-track-commit-timestamp"><varname>track_commit_timestamp</varname></link>
       is enabled on the subscriber. Currently, the update is always applied
       regardless of the origin of the local row.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry id="conflict-update-exists" xreflabel="update_exists">
     <term><literal>update_exists</literal></term>
     <listitem>
      <para>
       The updated value of a row violates a <literal>NOT DEFERRABLE</literal>
       unique constraint. Note that to log the origin and commit
       timestamp details of the conflicting key,
       <link linkend="guc-track-commit-timestamp"><varname>track_commit_timestamp</varname></link>
       should be enabled on the subscriber. In this case, an error will be
       raised until the conflict is resolved manually. Note that when updating a
       partitioned table, if the updated row value satisfies another partition
       constraint resulting in the row being inserted into a new partition, the
       <literal>insert_exists</literal> conflict may arise if the new row
       violates a <literal>NOT DEFERRABLE</literal> unique constraint.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry id="conflict-update-missing" xreflabel="update_missing">
     <term><literal>update_missing</literal></term>
     <listitem>
      <para>
       The tuple to be updated was not found. The update will simply be
       skipped in this scenario.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry id="conflict-delete-origin-differs" xreflabel="delete_origin_differs">
     <term><literal>delete_origin_differs</literal></term>
     <listitem>
      <para>
       Deleting a row that was previously modified by another origin. Note that
       this conflict can only be detected when
       <link linkend="guc-track-commit-timestamp"><varname>track_commit_timestamp</varname></link>
       is enabled on the subscriber. Currently, the delete is always applied
       regardless of the origin of the local row.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry id="conflict-delete-missing" xreflabel="delete_missing">
     <term><literal>delete_missing</literal></term>
     <listitem>
      <para>
       The tuple to be deleted was not found. The delete will simply be
       skipped in this scenario.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry id="conflict-multiple-unique-conflicts" xreflabel="multiple_unique_conflicts">
     <term><literal>multiple_unique_conflicts</literal></term>
     <listitem>
      <para>
       Inserting or updating a row violates multiple
       <literal>NOT DEFERRABLE</literal> unique constraints. Note that to log
       the origin and commit timestamp details of conflicting keys, ensure
       that <link linkend="guc-track-commit-timestamp"><varname>track_commit_timestamp</varname></link>
       is enabled on the subscriber. In this case, an error will be raised until
       the conflict is resolved manually.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
    Note that there are other conflict scenarios, such as exclusion constraint
    violations. Currently, we do not provide additional details for them in the
    log.
  </para>

  <para>
   The log format for logical replication conflicts is as follows:
<synopsis>
LOG:  conflict detected on relation "<replaceable>schemaname</replaceable>.<replaceable>tablename</replaceable>": conflict=<replaceable>conflict_type</replaceable>
DETAIL:  <replaceable class="parameter">detailed_explanation</replaceable>.
{<replaceable class="parameter">detail_values</replaceable> [; ... ]}.

<phrase>where <replaceable class="parameter">detail_values</replaceable> is one of:</phrase>

    <literal>Key</literal> (<replaceable>column_name</replaceable> <optional>,