to <literal>any</literal> means that the publisher sends changes
          regardless of their origin. The default is <literal>any</literal>.
         </para>
         <para>
          See <xref linkend="sql-createsubscription-notes"/> for details of how
          <literal>copy_data = true</literal> can interact with the
          <literal>origin</literal> parameter.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry id="sql-createsubscription-params-with-failover">
        <term><literal>failover</literal> (<type>boolean</type>)</term>
        <listitem>
         <para>
          Specifies whether the replication slots associated with the subscription
          are enabled to be synced to the standbys so that logical
          replication can be resumed from the new primary after failover.
          The default is <literal>false</literal>.
         </para>
        </listitem>
       </varlistentry>
      </variablelist></para>

    </listitem>
   </varlistentry>
  </variablelist>

  <para>
   When specifying a parameter of type <type>boolean</type>, the
   <literal>=</literal> <replaceable class="parameter">value</replaceable>
   part can be omitted, which is equivalent to
   specifying <literal>TRUE</literal>.
  </para>
 </refsect1>

 <refsect1 id="sql-createsubscription-notes" xreflabel="Notes">
  <title>Notes</title>

  <para>
   See <xref linkend="logical-replication-security"/> for details on
   how to configure access control between the subscription and the
   publication instance.
  </para>

  <para>
   When creating a replication slot (the default behavior), <command>CREATE
   SUBSCRIPTION</command> cannot be executed inside a transaction block.
  </para>

  <para>
   Creating a subscription that connects to the same database cluster (for
   example, to replicate between databases in the same cluster or to replicate
   within the same database) will only succeed if the replication slot is not
   created as part of the same command.  Otherwise, the <command>CREATE
   SUBSCRIPTION</command> call will hang.  To make this work, create the
   replication slot separately (using the
   function <function>pg_create_logical_replication_slot</function> with the
   plugin name <literal>pgoutput</literal>) and create the subscription using
   the parameter <literal>create_slot = false</literal>.  See
   <xref linkend="logical-replication-subscription-examples-deferred-slot"/>
   for examples. This is an implementation restriction that might be lifted in a
   future release.
  </para>

  <para>
   If any table in the publication has a <literal>WHERE</literal> clause, rows
   for which the <replaceable class="parameter">expression</replaceable>
   evaluates to <literal>false</literal> or <literal>NULL</literal> will not be
   published. If the subscription has
   several publications in which the same table has been published with
   different <literal>WHERE</literal> clauses, a row will be published if any
   of the expressions (referring to that publish operation) are satisfied. In
   the case of different <literal>WHERE</literal> clauses, if one of the
   publications has no <literal>WHERE</literal> clause (referring to that
   publish operation) or the publication is declared as
   <link linkend="sql-createpublication-params-for-all-tables"><literal>FOR ALL TABLES</literal></link>
   or <link linkend="sql-createpublication-params-for-tables-in-schema"><literal>FOR TABLES IN SCHEMA</literal></link>,
   rows are always published regardless of the definition of the other
   expressions. If the subscriber is a <productname>PostgreSQL</productname>
   version before 15, then any row filtering is ignored during the initial data
   synchronization phase.