Home • Explore • Blog • CI
☰



postgresql
3rd chunk of `doc/src/sgml/ref/create_subscription.sgml`
214709591cd34fc7bcb57dd1d0b6992d47d21da45c5ad2160000000100000fa2
 should just be set up but not started yet.  The default
          is <literal>true</literal>.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry id="sql-createsubscription-params-with-slot-name">
        <term><literal>slot_name</literal> (<type>string</type>)</term>
        <listitem>
         <para>
          Name of the publisher's replication slot to use.  The default is
          to use the name of the subscription for the slot name.
         </para>

         <para>
          Setting <literal>slot_name</literal> to <literal>NONE</literal>
          means there will be no replication slot associated with the
          subscription. Such subscriptions must also have both
          <literal>enabled</literal> and <literal>create_slot</literal> set to
          <literal>false</literal>.  Use this when you will be creating the
          replication slot later manually. See
          <xref linkend="logical-replication-subscription-examples-deferred-slot"/>
          for examples.
         </para>

         <para>
          When setting <literal>slot_name</literal> to a valid name and
          <literal>create_slot</literal> to <literal>false</literal>, the
          <literal>failover</literal> property value of the named slot may
          differ from the counterpart <literal>failover</literal> parameter
          specified in the subscription. Always ensure the slot property
          <literal>failover</literal> matches the counterpart parameter of the
          subscription and vice versa. Otherwise, the slot on the publisher may
          behave differently from what these subscription options say: for
          example, the slot on the publisher could either be synced to the
          standbys even when the subscription's <literal>failover</literal>
          option is disabled or could be disabled for sync even when the
          subscription's <literal>failover</literal> option is enabled.
         </para>
        </listitem>
       </varlistentry>
      </variablelist>
     </para>

     <para>
      The following parameters control the subscription's replication
      behavior after it has been created:

      <variablelist>

       <varlistentry id="sql-createsubscription-params-with-binary">
        <term><literal>binary</literal> (<type>boolean</type>)</term>
        <listitem>
         <para>
          Specifies whether the subscription will request the publisher to send
          the data in binary format (as opposed to text). The default is
          <literal>false</literal>. Any initial table synchronization copy
          (see <literal>copy_data</literal>) also uses the same format. Binary
          format can be faster than the text format, but it is less portable
          across machine architectures and <productname>PostgreSQL</productname>
          versions. Binary format is very data type specific; for example, it
          will not allow copying from a <type>smallint</type> column to an
          <type>integer</type> column, even though that would work fine in text
          format. Even when this option is enabled, only data types having binary
          send and receive functions will be transferred in binary. Note that
          the initial synchronization requires all data types to have binary
          send and receive functions, otherwise the synchronization will fail
          (see <xref linkend="sql-createtype"/> for more about send/receive
          functions).
         </para>

         <para>
          When doing cross-version replication, it could be that the
          publisher has a binary send function for some data type, but the
          subscriber lacks a binary receive function for that type.  In
          such a case, data transfer will fail, and
          the <literal>binary</literal> option cannot be used.
         </para>

         <para>
          If the publisher is a <productname>PostgreSQL</productname> version
          before 16, then any initial
Title: CREATE SUBSCRIPTION WITH Clause Parameters (Continued)
Summary
Continuing the explanation of the `WITH` clause parameters for `CREATE SUBSCRIPTION`, this section describes `slot_name` in more detail, including its interaction with `create_slot` and `failover`. It then introduces the parameters that control replication behavior after subscription creation, focusing on the `binary` parameter, which specifies whether data should be transferred in binary or text format. Binary format can be faster but less portable.