Home • Explore • Blog • CI
☰



postgresql
21th chunk of `doc/src/sgml/logical-replication.sgml`
e38ef3d228073777d89b384c81c2c5b1cc1034e909c6efc00000000100000fa0
   <entry>GENERATED</entry>
      <entry>GENERATED</entry>
      <entry>ERROR. Not supported.</entry>
     </row>

     <row>
      <entry>Yes</entry>
      <entry>GENERATED</entry>
      <entry>regular</entry>
      <entry>Publisher table column value is replicated to the subscriber table column.</entry>
     </row>

     <row>
      <entry>Yes</entry>
      <entry>GENERATED</entry>
      <entry>--missing--</entry>
      <entry>ERROR. The column is reported as missing from the subscriber table.</entry>
     </row>
    </tbody>
   </tgroup>
  </table>

  <warning>
   <para>
    There's currently no support for subscriptions comprising several
    publications where the same table has been published with different column
    lists. See <xref linkend="logical-replication-col-lists"/>.
   </para>

   <para>
    This same situation can occur if one publication is publishing generated
    columns, while another publication in the same subscription is not
    publishing generated columns for the same table.
   </para>
  </warning>

  <note>
   <para>
    If the subscriber is from a release prior to 18, then initial table
    synchronization won't copy generated columns even if they are defined in
    the publisher.
   </para>
  </note>
 </sect1>

 <sect1 id="logical-replication-conflicts">
  <title>Conflicts</title>

  <para>
   Logical replication behaves similarly to normal DML operations in that
   the data will be updated even if it was changed locally on the subscriber
   node.  If incoming data violates any constraints the replication will
   stop.  This is referred to as a <firstterm>conflict</firstterm>.  When
   replicating <command>UPDATE</command> or <command>DELETE</command>
   operations, missing data is also considered as a
   <firstterm>conflict</firstterm>, but does not result in an error and such
   operations will simply be skipped.
  </para>

  <para>
   Additional logging is triggered, and the conflict statistics are collected (displayed in the
   <link linkend="monitoring-pg-stat-subscription-stats"><structname>pg_stat_subscription_stats</structname></link> view)
   in the following <firstterm>conflict</firstterm> cases:
   <variablelist>
    <varlistentry id="conflict-insert-exists" xreflabel="insert_exists">
     <term><literal>insert_exists</literal></term>
     <listitem>
      <para>
       Inserting a row that 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.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry id="conflict-update-origin-differs" xreflabel="update_origin_differs">
     <term><literal>update_origin_differs</literal></term>
     <listitem>
      <para>
       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
Title: Generated Column Replication Limitations, Behavior on Older Subscribers, and Replication Conflicts
Summary
This section discusses limitations related to subscriptions with multiple publications and generated columns, noting that the subscriber will not copy generated columns during initial synchronization if it's from a release prior to version 18. It also explains how logical replication handles conflicts, similar to normal DML operations, where data is updated even if locally changed, and constraint violations halt replication. The section further details specific conflict cases ('insert_exists', 'update_origin_differs', 'update_exists'), including logging behavior and the importance of the 'track_commit_timestamp' setting for conflict detection and resolution.