2017-01-19 18:00:00 +01:00
|
|
|
<!--
|
|
|
|
doc/src/sgml/ref/drop_subscription.sgml
|
|
|
|
PostgreSQL documentation
|
|
|
|
-->
|
|
|
|
|
2017-10-20 03:16:39 +02:00
|
|
|
<refentry id="sql-dropsubscription">
|
2017-01-19 18:00:00 +01:00
|
|
|
<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>
|
2017-05-09 16:20:42 +02:00
|
|
|
DROP SUBSCRIPTION [ IF EXISTS ] <replaceable class="parameter">name</replaceable> [ CASCADE | RESTRICT ]
|
2017-01-19 18:00:00 +01:00
|
|
|
</synopsis>
|
|
|
|
</refsynopsisdiv>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Description</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
<command>DROP SUBSCRIPTION</command> removes a subscription from the
|
|
|
|
database cluster.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
Add new predefined role pg_create_subscription.
This role can be granted to non-superusers to allow them to issue
CREATE SUBSCRIPTION. The non-superuser must additionally have CREATE
permissions on the database in which the subscription is to be
created.
Most forms of ALTER SUBSCRIPTION, including ALTER SUBSCRIPTION .. SKIP,
now require only that the role performing the operation own the
subscription, or inherit the privileges of the owner. However, to
use ALTER SUBSCRIPTION ... RENAME or ALTER SUBSCRIPTION ... OWNER TO,
you also need CREATE permission on the database. This is similar to
what we do for schemas. To change the owner of a schema, you must also
have permission to SET ROLE to the new owner, similar to what we do
for other object types.
Non-superusers are required to specify a password for authentication
and the remote side must use the password, similar to what is required
for postgres_fdw and dblink. A superuser who wants a non-superuser to
own a subscription that does not rely on password authentication may
set the new password_required=false property on that subscription. A
non-superuser may not set password_required=false and may not modify a
subscription that already has password_required=false.
This new password_required subscription property works much like the
eponymous postgres_fdw property. In both cases, the actual semantics
are that a password is not required if either (1) the property is set
to false or (2) the relevant user is the superuser.
Patch by me, reviewed by Andres Freund, Jeff Davis, Mark Dilger,
and Stephen Frost (but some of those people did not fully endorse
all of the decisions that the patch makes).
Discussion: http://postgr.es/m/CA+TgmoaDH=0Xj7OBiQnsHTKcF2c4L+=gzPBUKSJLh8zed2_+Dg@mail.gmail.com
2023-03-30 17:37:19 +02:00
|
|
|
To execute this command the user must be the owner of the subscription.
|
2017-01-19 18:00:00 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
2017-03-04 05:25:34 +01:00
|
|
|
<command>DROP SUBSCRIPTION</command> cannot be executed inside a
|
2017-05-09 16:20:42 +02:00
|
|
|
transaction block if the subscription is associated with a replication
|
2023-10-13 08:43:46 +02:00
|
|
|
slot. (You can use <link linkend="sql-altersubscription"><command>ALTER SUBSCRIPTION</command></link> to unset the
|
2017-05-09 16:20:42 +02:00
|
|
|
slot.)
|
2017-01-19 18:00:00 +01:00
|
|
|
</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>
|
2017-05-09 16:20:42 +02:00
|
|
|
<term><literal>CASCADE</literal></term>
|
|
|
|
<term><literal>RESTRICT</literal></term>
|
2017-01-19 18:00:00 +01:00
|
|
|
|
2017-05-09 16:20:42 +02:00
|
|
|
<listitem>
|
2017-01-19 18:00:00 +01:00
|
|
|
<para>
|
2017-05-09 16:20:42 +02:00
|
|
|
These key words do not have any effect, since there are no dependencies
|
|
|
|
on subscriptions.
|
2017-01-19 18:00:00 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
</variablelist>
|
|
|
|
</refsect1>
|
|
|
|
|
2017-06-01 04:35:33 +02:00
|
|
|
<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>
|
Allow multiple xacts during table sync in logical replication.
For the initial table data synchronization in logical replication, we use
a single transaction to copy the entire table and then synchronize the
position in the stream with the main apply worker.
There are multiple downsides of this approach: (a) We have to perform the
entire copy operation again if there is any error (network breakdown,
error in the database operation, etc.) while we synchronize the WAL
position between tablesync worker and apply worker; this will be onerous
especially for large copies, (b) Using a single transaction in the
synchronization-phase (where we can receive WAL from multiple
transactions) will have the risk of exceeding the CID limit, (c) The slot
will hold the WAL till the entire sync is complete because we never commit
till the end.
This patch solves all the above downsides by allowing multiple
transactions during the tablesync phase. The initial copy is done in a
single transaction and after that, we commit each transaction as we
receive. To allow recovery after any error or crash, we use a permanent
slot and origin to track the progress. The slot and origin will be removed
once we finish the synchronization of the table. We also remove slot and
origin of tablesync workers if the user performs DROP SUBSCRIPTION .. or
ALTER SUBSCRIPTION .. REFERESH and some of the table syncs are still not
finished.
The commands ALTER SUBSCRIPTION ... REFRESH PUBLICATION and
ALTER SUBSCRIPTION ... SET PUBLICATION ... with refresh option as true
cannot be executed inside a transaction block because they can now drop
the slots for which we have no provision to rollback.
This will also open up the path for logical replication of 2PC
transactions on the subscriber side. Previously, we can't do that because
of the requirement of maintaining a single transaction in tablesync
workers.
Bump catalog version due to change of state in the catalog
(pg_subscription_rel).
Author: Peter Smith, Amit Kapila, and Takamichi Osumi
Reviewed-by: Ajin Cherian, Petr Jelinek, Hou Zhijie and Amit Kapila
Discussion: https://postgr.es/m/CAA4eK1KHJxaZS-fod-0fey=0tq3=Gkn4ho=8N4-5HWiCfu0H1A@mail.gmail.com
2021-02-12 03:11:51 +01:00
|
|
|
will connect to the remote host and try to drop the replication slot (and
|
|
|
|
any remaining table synchronization slots) as
|
2017-06-01 04:35:33 +02:00
|
|
|
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,
|
2023-06-21 07:06:09 +02:00
|
|
|
the <command>DROP SUBSCRIPTION</command> command will fail. To proceed
|
|
|
|
in this situation, first disable the subscription by executing
|
2023-10-13 08:43:46 +02:00
|
|
|
<link linkend="sql-altersubscription-params-disable">
|
|
|
|
<literal>ALTER SUBSCRIPTION ... DISABLE</literal></link>, and then disassociate
|
2023-06-21 07:06:09 +02:00
|
|
|
it from the replication slot by executing
|
2023-10-13 08:43:46 +02:00
|
|
|
<link linkend="sql-altersubscription-params-set">
|
|
|
|
<literal>ALTER SUBSCRIPTION ... SET (slot_name = NONE)</literal></link>.
|
2017-06-01 04:35:33 +02:00
|
|
|
After that, <command>DROP SUBSCRIPTION</command> will no longer attempt any
|
|
|
|
actions on a remote host. Note that if the remote replication slot still
|
Allow multiple xacts during table sync in logical replication.
For the initial table data synchronization in logical replication, we use
a single transaction to copy the entire table and then synchronize the
position in the stream with the main apply worker.
There are multiple downsides of this approach: (a) We have to perform the
entire copy operation again if there is any error (network breakdown,
error in the database operation, etc.) while we synchronize the WAL
position between tablesync worker and apply worker; this will be onerous
especially for large copies, (b) Using a single transaction in the
synchronization-phase (where we can receive WAL from multiple
transactions) will have the risk of exceeding the CID limit, (c) The slot
will hold the WAL till the entire sync is complete because we never commit
till the end.
This patch solves all the above downsides by allowing multiple
transactions during the tablesync phase. The initial copy is done in a
single transaction and after that, we commit each transaction as we
receive. To allow recovery after any error or crash, we use a permanent
slot and origin to track the progress. The slot and origin will be removed
once we finish the synchronization of the table. We also remove slot and
origin of tablesync workers if the user performs DROP SUBSCRIPTION .. or
ALTER SUBSCRIPTION .. REFERESH and some of the table syncs are still not
finished.
The commands ALTER SUBSCRIPTION ... REFRESH PUBLICATION and
ALTER SUBSCRIPTION ... SET PUBLICATION ... with refresh option as true
cannot be executed inside a transaction block because they can now drop
the slots for which we have no provision to rollback.
This will also open up the path for logical replication of 2PC
transactions on the subscriber side. Previously, we can't do that because
of the requirement of maintaining a single transaction in tablesync
workers.
Bump catalog version due to change of state in the catalog
(pg_subscription_rel).
Author: Peter Smith, Amit Kapila, and Takamichi Osumi
Reviewed-by: Ajin Cherian, Petr Jelinek, Hou Zhijie and Amit Kapila
Discussion: https://postgr.es/m/CAA4eK1KHJxaZS-fod-0fey=0tq3=Gkn4ho=8N4-5HWiCfu0H1A@mail.gmail.com
2021-02-12 03:11:51 +01:00
|
|
|
exists, it (and any related table synchronization slots) should then be
|
|
|
|
dropped manually; otherwise it/they will continue to
|
2017-06-01 04:35:33 +02:00
|
|
|
reserve WAL and might eventually cause the disk to fill up. See
|
2017-11-23 15:39:47 +01:00
|
|
|
also <xref linkend="logical-replication-subscription-slot"/>.
|
2017-06-01 04:35:33 +02:00
|
|
|
</para>
|
2017-09-22 21:01:13 +02:00
|
|
|
|
|
|
|
<para>
|
|
|
|
If a subscription is associated with a replication slot, then <command>DROP
|
|
|
|
SUBSCRIPTION</command> cannot be executed inside a transaction block.
|
|
|
|
</para>
|
2017-06-01 04:35:33 +02:00
|
|
|
</refsect1>
|
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
<refsect1>
|
|
|
|
<title>Examples</title>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
Drop a subscription:
|
|
|
|
<programlisting>
|
|
|
|
DROP SUBSCRIPTION mysub;
|
2017-06-14 19:55:43 +02:00
|
|
|
</programlisting></para>
|
2017-01-19 18:00:00 +01:00
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Compatibility</title>
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
<command>DROP SUBSCRIPTION</command> is a <productname>PostgreSQL</productname>
|
2017-01-19 18:00:00 +01:00
|
|
|
extension.
|
|
|
|
</para>
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>See Also</title>
|
|
|
|
|
|
|
|
<simplelist type="inline">
|
2017-11-23 15:39:47 +01:00
|
|
|
<member><xref linkend="sql-createsubscription"/></member>
|
|
|
|
<member><xref linkend="sql-altersubscription"/></member>
|
2017-01-19 18:00:00 +01:00
|
|
|
</simplelist>
|
|
|
|
</refsect1>
|
|
|
|
</refentry>
|