Home • Explore • Blog • CI
☰



postgresql
5th chunk of `doc/src/sgml/ref/create_subscription.sgml`
ed28821315bff5ad9453cc0bd71f30f0b2d7dece8f8d94b50000000100000fa0
 subscriber differ, although such cases are rare. The apply worker
           is equipped to retry these transactions automatically.
          </para>
         </caution>

         <para>
          If set to <literal>on</literal>, the incoming changes are written to
          temporary files and then applied only after the transaction is
          committed on the publisher and received by the subscriber.
         </para>

         <para>
          If set to <literal>off</literal>, all transactions are fully decoded
          on the publisher and only then sent to the subscriber as a whole.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry id="sql-createsubscription-params-with-synchronous-commit">
        <term><literal>synchronous_commit</literal> (<type>enum</type>)</term>
        <listitem>
         <para>
          The value of this parameter overrides the
          <xref linkend="guc-synchronous-commit"/> setting within this
          subscription's apply worker processes.  The default value
          is <literal>off</literal>.
         </para>

         <para>
          It is safe to use <literal>off</literal> for logical replication:
          If the subscriber loses transactions because of missing
          synchronization, the data will be sent again from the publisher.
         </para>

         <para>
          A different setting might be appropriate when doing synchronous
          logical replication.  The logical replication workers report the
          positions of writes and flushes to the publisher, and when using
          synchronous replication, the publisher will wait for the actual
          flush.  This means that setting
          <literal>synchronous_commit</literal> for the subscriber to
          <literal>off</literal> when the subscription is used for
          synchronous replication might increase the latency for
          <command>COMMIT</command> on the publisher.  In this scenario, it
          can be advantageous to set <literal>synchronous_commit</literal>
          to <literal>local</literal> or higher.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry id="sql-createsubscription-params-with-two-phase">
        <term><literal>two_phase</literal> (<type>boolean</type>)</term>
        <listitem>
         <para>
          Specifies whether two-phase commit is enabled for this subscription.
          The default is <literal>false</literal>.
         </para>

         <para>
          When two-phase commit is enabled, prepared transactions are sent
          to the subscriber at the time of <command>PREPARE
          TRANSACTION</command>, and are processed as two-phase
          transactions on the subscriber too.  Otherwise, prepared
          transactions are sent to the subscriber only when committed, and
          are then processed immediately by the subscriber.
         </para>

         <para>
          The implementation of two-phase commit requires that replication
          has successfully finished the initial table synchronization
          phase. So even when <literal>two_phase</literal> is enabled for a
          subscription, the internal two-phase state remains
          temporarily <quote>pending</quote> until the initialization phase
          completes. See column <structfield>subtwophasestate</structfield>
          of <link linkend="catalog-pg-subscription"><structname>pg_subscription</structname></link>
          to know the actual two-phase state.
         </para>

        </listitem>
       </varlistentry>

       <varlistentry id="sql-createsubscription-params-with-disable-on-error">
        <term><literal>disable_on_error</literal> (<type>boolean</type>)</term>
        <listitem>
         <para>
          Specifies whether the subscription should be automatically disabled
          if any errors are detected by subscription workers during data
          replication from the publisher. The default is
Title: CREATE SUBSCRIPTION WITH Clause Parameters (Continued): synchronous_commit, two_phase, disable_on_error
Summary
This section continues detailing `WITH` clause parameters for `CREATE SUBSCRIPTION`. It describes `synchronous_commit`, which overrides the global setting for apply worker processes, explaining the safety of using `off` and considerations for synchronous logical replication. It then covers `two_phase`, enabling two-phase commit for prepared transactions, noting the dependency on initial table synchronization. Finally, it starts to describe the `disable_on_error` parameter.