<!--
doc/src/sgml/ref/drop_subscription.sgml
PostgreSQL documentation
-->

<refentry id="sql-dropsubscription">
 <indexterm zone="sql-dropsubscription">
  <primary>DROP SUBSCRIPTION</primary>
 </indexterm>

 <refmeta>
  <refentrytitle>DROP SUBSCRIPTION</refentrytitle>
  <manvolnum>7</manvolnum>
  <refmiscinfo>SQL - Language Statements</refmiscinfo>
 </refmeta>

 <refnamediv>
  <refname>DROP SUBSCRIPTION</refname>
  <refpurpose>remove a subscription</refpurpose>
 </refnamediv>

 <refsynopsisdiv>
<synopsis>
DROP SUBSCRIPTION [ IF EXISTS ] <replaceable class="parameter">name</replaceable> [ CASCADE | RESTRICT ]
</synopsis>
 </refsynopsisdiv>

 <refsect1>
  <title>Description</title>

  <para>
   <command>DROP SUBSCRIPTION</command> removes a subscription from the
   database cluster.
  </para>

  <para>
   To execute this command the user must be the owner of the subscription.
  </para>

  <para>
   <command>DROP SUBSCRIPTION</command> cannot be executed inside a
   transaction block if the subscription is associated with a replication
   slot.  (You can use <link linkend="sql-altersubscription"><command>ALTER SUBSCRIPTION</command></link> to unset the
   slot.)
  </para>
 </refsect1>

 <refsect1>
  <title>Parameters</title>

  <variablelist>
   <varlistentry>
    <term><replaceable class="parameter">name</replaceable></term>
    <listitem>
     <para>
      The name of a subscription to be dropped.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>CASCADE</literal></term>
    <term><literal>RESTRICT</literal></term>

    <listitem>
     <para>
      These key words do not have any effect, since there are no dependencies
      on subscriptions.
     </para>
    </listitem>
   </varlistentry>

  </variablelist>
 </refsect1>

 <refsect1>
  <title>Notes</title>

  <para>
   When dropping a subscription that is associated with a replication slot on
   the remote host (the normal state), <command>DROP SUBSCRIPTION</command>
   will connect to the remote host and try to drop the replication slot (and
   any remaining table synchronization slots) as
   part of its operation.  This is necessary so that the resources allocated
   for the subscription on the remote host are released.  If this fails,
   either because the remote host is not reachable or because the remote
   replication slot cannot be dropped or does not exist or never existed,
   the <command>DROP SUBSCRIPTION</command> command will fail.  To proceed
   in this situation, first disable the subscription by executing
   <link linkend="sql-altersubscription-params-disable">
   <literal>ALTER SUBSCRIPTION ... DISABLE</literal></link>, and then disassociate
   it from the replication slot by executing
   <link linkend="sql-altersubscription-params-set">
   <literal>ALTER SUBSCRIPTION ... SET (slot_name = NONE)</literal></link>.
   After that, <command>DROP SUBSCRIPTION</command> will no longer attempt any
   actions on a remote host.  Note that if the remote replication slot still
   exists, it (and any related table synchronization slots) should then be
   dropped manually; otherwise it/they will continue to
   reserve WAL and might eventually cause the disk to fill up.  See
   also <xref linkend="logical-replication-subscription-slot"/>.
  </para>

  <para>
   If a subscription is associated with a replication slot, then <command>DROP
   SUBSCRIPTION</command> cannot be executed inside a transaction block.
  </para>
 </refsect1>

 <refsect1>
  <title>Examples</title>

  <para>
   Drop a subscription:
<programlisting>
DROP SUBSCRIPTION mysub;
</programlisting></para>
 </refsect1>

 <refsect1>
  <title>Compatibility</title>

  <para>
   <command>DROP SUBSCRIPTION</command> is a <productname>PostgreSQL</productname>
   extension.
  </para>
 </refsect1>

 <refsect1>
  <title>See Also</title>

  <simplelist type="inline">
   <member><xref linkend="sql-createsubscription"/></member>
   <member><xref linkend="sql-altersubscription"/></member>
  </simplelist>
 </refsect1>
</refentry>