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>, ...</optional>)=(<replaceable>column_value</replaceable> <optional>, ...</optional>)
    <literal>existing local tuple</literal> <optional>(<replaceable>column_name</replaceable> <optional>, ...</optional>)=</optional>(<replaceable>column_value</replaceable> <optional>, ...</optional>)
    <literal>remote tuple</literal> <optional>(<replaceable>column_name</replaceable> <optional>, ...</optional>)=</optional>(<replaceable>column_value</replaceable> <optional>, ...</optional>)
    <literal>replica identity</literal> {(<replaceable>column_name</replaceable> <optional>, ...</optional>)=(<replaceable>column_value</replaceable> <optional>, ...</optional>) | full <optional>(<replaceable>column_name</replaceable> <optional>, ...</optional>)=</optional>(<replaceable>column_value</replaceable> <optional>, ...</optional>)}
</synopsis>

   The log provides the following information:
   <variablelist>
    <varlistentry>
     <term><literal>LOG</literal></term>
      <listitem>
       <itemizedlist>
        <listitem>
         <para>
         <replaceable>schemaname</replaceable>.<replaceable>tablename</replaceable>
         identifies the local relation involved in the conflict.
         </para>
        </listitem>
        <listitem>
         <para>
         <replaceable>conflict_type</replaceable> is the type of conflict that occurred
         (e.g., <literal>insert_exists</literal>, <literal>update_exists</literal>).
         </para>
        </listitem>
       </itemizedlist>
      </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>DETAIL</literal></term>
      <listitem>
      <itemizedlist>
       <listitem>
        <para>
         <replaceable class="parameter">detailed_explanation</replaceable> includes
         the origin, transaction ID, and commit timestamp of the transaction that
         modified the existing local tuple, if available.
        </para>
       </listitem>
       <listitem>
        <para>
         The <literal>Key</literal> section includes the key values of the local
         tuple that violated a unique constraint for
         <literal>insert_exists</literal>, <literal>update_exists</literal> or
         <literal>multiple_unique_conflicts</literal> conflicts.
        </para>
       </listitem>
       <listitem>
        <para>
         The <literal>existing local tuple</literal> section includes the local
         tuple if its origin differs from the remote tuple for
         <literal>update_origin_differs</literal> or <literal>delete_origin_differs</literal>
         conflicts, or if the key value conflicts with the remote tuple for
         <literal>insert_exists</literal>, <literal>update_exists</literal> or
         <literal>multiple_unique_conflicts</literal> conflicts.
        </para>
       </listitem>
       <listitem>
        <para>
         The <literal>remote tuple</literal> section includes the new tuple from
         the remote insert or update operation that caused the