2017-01-19 18:00:00 +01:00
|
|
|
<!--
|
|
|
|
|
doc/src/sgml/ref/alter_subscription.sgml
|
|
|
|
|
PostgreSQL documentation
|
|
|
|
|
-->
|
|
|
|
|
|
2017-10-20 03:16:39 +02:00
|
|
|
<refentry id="sql-altersubscription">
|
2017-01-19 18:00:00 +01:00
|
|
|
<indexterm zone="sql-altersubscription">
|
|
|
|
|
<primary>ALTER SUBSCRIPTION</primary>
|
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
|
|
<refmeta>
|
|
|
|
|
<refentrytitle>ALTER SUBSCRIPTION</refentrytitle>
|
|
|
|
|
<manvolnum>7</manvolnum>
|
|
|
|
|
<refmiscinfo>SQL - Language Statements</refmiscinfo>
|
|
|
|
|
</refmeta>
|
|
|
|
|
|
|
|
|
|
<refnamediv>
|
|
|
|
|
<refname>ALTER SUBSCRIPTION</refname>
|
|
|
|
|
<refpurpose>change the definition of a subscription</refpurpose>
|
|
|
|
|
</refnamediv>
|
|
|
|
|
|
|
|
|
|
<refsynopsisdiv>
|
|
|
|
|
<synopsis>
|
2017-10-09 04:00:57 +02:00
|
|
|
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> CONNECTION '<replaceable>conninfo</replaceable>'
|
|
|
|
|
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> SET PUBLICATION <replaceable class="parameter">publication_name</replaceable> [, ...] [ WITH ( <replaceable class="parameter">set_publication_option</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ]
|
|
|
|
|
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> REFRESH PUBLICATION [ WITH ( <replaceable class="parameter">refresh_option</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ]
|
|
|
|
|
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> ENABLE
|
|
|
|
|
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> DISABLE
|
|
|
|
|
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> SET ( <replaceable class="parameter">subscription_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] )
|
2020-09-17 11:39:28 +02:00
|
|
|
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> OWNER TO { <replaceable>new_owner</replaceable> | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
|
2017-10-09 04:00:57 +02:00
|
|
|
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> RENAME TO <replaceable>new_name</replaceable>
|
2017-01-19 18:00:00 +01:00
|
|
|
</synopsis>
|
|
|
|
|
</refsynopsisdiv>
|
|
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
|
<title>Description</title>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
<command>ALTER SUBSCRIPTION</command> can change most of the subscription
|
|
|
|
|
properties that can be specified
|
2017-11-23 15:39:47 +01:00
|
|
|
in <xref linkend="sql-createsubscription"/>.
|
2017-01-19 18:00:00 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
2017-10-09 03:44:17 +02:00
|
|
|
You must own the subscription to use <command>ALTER SUBSCRIPTION</command>.
|
2017-01-19 18:00:00 +01:00
|
|
|
To alter the owner, you must also be a direct or indirect member of the
|
2017-04-26 18:05:11 +02:00
|
|
|
new owning role. The new owner has to be a superuser.
|
2017-05-30 17:47:19 +02:00
|
|
|
(Currently, all subscription owners must be superusers, so the owner checks
|
|
|
|
|
will be bypassed in practice. But this might change in the future.)
|
2017-01-19 18:00:00 +01:00
|
|
|
</para>
|
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
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
When refreshing a publication we remove the relations that are no longer
|
2021-03-31 04:47:50 +02:00
|
|
|
part of the publication and we also remove the table synchronization slots
|
|
|
|
|
if there are any. It is necessary to remove these slots so that the resources
|
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
|
|
|
allocated for the subscription on the remote host are released. If due to
|
|
|
|
|
network breakdown or some other error, <productname>PostgreSQL</productname>
|
|
|
|
|
is unable to remove the slots, an ERROR will be reported. To proceed in this
|
2021-02-24 08:13:17 +01:00
|
|
|
situation, the user either needs to retry the operation or disassociate the
|
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
|
|
|
slot from the subscription and drop the subscription as explained in
|
|
|
|
|
<xref linkend="sql-dropsubscription"/>.
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Commands <command>ALTER SUBSCRIPTION ... REFRESH PUBLICATION</command> and
|
|
|
|
|
<command>ALTER SUBSCRIPTION ... SET PUBLICATION ...</command> with refresh
|
|
|
|
|
option as true cannot be executed inside a transaction block.
|
|
|
|
|
</para>
|
2017-01-19 18:00:00 +01:00
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
|
<title>Parameters</title>
|
|
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><replaceable class="parameter">name</replaceable></term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
The name of a subscription whose properties are to be altered.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><literal>CONNECTION '<replaceable class="parameter">conninfo</replaceable>'</literal></term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
2017-05-12 14:57:01 +02:00
|
|
|
This clause alters the connection property originally set by
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="sql-createsubscription"/>. See there for more
|
2017-01-19 18:00:00 +01:00
|
|
|
information.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2017-03-23 13:36:36 +01:00
|
|
|
<varlistentry>
|
|
|
|
|
<term><literal>SET PUBLICATION <replaceable class="parameter">publication_name</replaceable></literal></term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Changes list of subscribed publications. See
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="sql-createsubscription"/> for more information.
|
2017-06-06 03:37:00 +02:00
|
|
|
By default this command will also act like <literal>REFRESH
|
|
|
|
|
PUBLICATION</literal>.
|
2017-03-23 13:36:36 +01:00
|
|
|
</para>
|
2017-05-12 14:57:01 +02:00
|
|
|
|
2017-03-23 13:36:36 +01:00
|
|
|
<para>
|
2017-06-06 03:37:00 +02:00
|
|
|
<replaceable>set_publication_option</replaceable> specifies additional
|
|
|
|
|
options for this operation. The supported options are:
|
|
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><literal>refresh</literal> (<type>boolean</type>)</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
When false, the command will not try to refresh table information.
|
|
|
|
|
<literal>REFRESH PUBLICATION</literal> should then be executed separately.
|
|
|
|
|
The default is <literal>true</literal>.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
</variablelist>
|
|
|
|
|
|
|
|
|
|
Additionally, refresh options as described
|
|
|
|
|
under <literal>REFRESH PUBLICATION</literal> may be specified.
|
2017-03-23 13:36:36 +01:00
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
2017-04-08 04:42:03 +02:00
|
|
|
<term><literal>REFRESH PUBLICATION</literal></term>
|
2017-03-23 13:36:36 +01:00
|
|
|
<listitem>
|
|
|
|
|
<para>
|
2017-05-12 14:57:01 +02:00
|
|
|
Fetch missing table information from publisher. This will start
|
2017-03-23 13:36:36 +01:00
|
|
|
replication of tables that were added to the subscribed-to publications
|
|
|
|
|
since the last invocation of <command>REFRESH PUBLICATION</command> or
|
|
|
|
|
since <command>CREATE SUBSCRIPTION</command>.
|
|
|
|
|
</para>
|
2017-05-12 14:57:01 +02:00
|
|
|
|
2017-03-23 13:36:36 +01:00
|
|
|
<para>
|
2017-06-06 03:37:00 +02:00
|
|
|
<replaceable>refresh_option</replaceable> specifies additional options for the
|
2017-05-12 14:57:01 +02:00
|
|
|
refresh operation. The supported options are:
|
|
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><literal>copy_data</literal> (<type>boolean</type>)</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Specifies whether the existing data in the publications that are
|
|
|
|
|
being subscribed to should be copied once the replication starts.
|
2020-02-05 17:21:43 +01:00
|
|
|
The default is <literal>true</literal>. (Previously subscribed
|
|
|
|
|
tables are not copied.)
|
2017-05-12 14:57:01 +02:00
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
2020-06-07 14:54:28 +02:00
|
|
|
</variablelist></para>
|
2017-03-23 13:36:36 +01:00
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2017-01-19 18:00:00 +01:00
|
|
|
<varlistentry>
|
|
|
|
|
<term><literal>ENABLE</literal></term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Enables the previously disabled subscription, starting the logical
|
|
|
|
|
replication worker at the end of transaction.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><literal>DISABLE</literal></term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Disables the running subscription, stopping the logical replication
|
|
|
|
|
worker at the end of transaction.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
2017-03-23 13:36:36 +01:00
|
|
|
|
2017-05-12 14:57:01 +02:00
|
|
|
<varlistentry>
|
|
|
|
|
<term><literal>SET ( <replaceable class="parameter">subscription_parameter</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] )</literal></term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
This clause alters parameters originally set by
|
2017-11-23 15:39:47 +01:00
|
|
|
<xref linkend="sql-createsubscription"/>. See there for more
|
2020-07-18 18:44:51 +02:00
|
|
|
information. The parameters that can be altered
|
|
|
|
|
are <literal>slot_name</literal>,
|
Add support for streaming to built-in logical replication.
To add support for streaming of in-progress transactions into the
built-in logical replication, we need to do three things:
* Extend the logical replication protocol, so identify in-progress
transactions, and allow adding additional bits of information (e.g.
XID of subtransactions).
* Modify the output plugin (pgoutput) to implement the new stream
API callbacks, by leveraging the extended replication protocol.
* Modify the replication apply worker, to properly handle streamed
in-progress transaction by spilling the data to disk and then
replaying them on commit.
We however must explicitly disable streaming replication during
replication slot creation, even if the plugin supports it. We
don't need to replicate the changes accumulated during this phase,
and moreover we don't have a replication connection open so we
don't have where to send the data anyway.
Author: Tomas Vondra, Dilip Kumar and Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Ajin Cherian
Tested-by: Neha Sharma, Mahendra Singh Thalor and Ajin Cherian
Discussion: https://postgr.es/m/688b0b7f-2f6c-d827-c27b-216a8e3ea700@2ndquadrant.com
2020-09-03 04:24:07 +02:00
|
|
|
<literal>synchronous_commit</literal>,
|
|
|
|
|
<literal>binary</literal>, and
|
|
|
|
|
<literal>streaming</literal>.
|
2017-05-12 14:57:01 +02:00
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2017-05-02 21:29:30 +02:00
|
|
|
<varlistentry>
|
|
|
|
|
<term><replaceable class="parameter">new_owner</replaceable></term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
The user name of the new owner of the subscription.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><replaceable class="parameter">new_name</replaceable></term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
The new name for the subscription.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
2017-01-19 18:00:00 +01:00
|
|
|
</variablelist>
|
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
|
<title>Examples</title>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Change the publication subscribed by a subscription to
|
|
|
|
|
<literal>insert_only</literal>:
|
|
|
|
|
<programlisting>
|
2017-06-06 03:37:00 +02:00
|
|
|
ALTER SUBSCRIPTION mysub SET PUBLICATION insert_only;
|
2017-01-19 18:00:00 +01:00
|
|
|
</programlisting>
|
|
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
Disable (stop) the subscription:
|
|
|
|
|
<programlisting>
|
|
|
|
|
ALTER SUBSCRIPTION mysub DISABLE;
|
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>ALTER 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-dropsubscription"/></member>
|
|
|
|
|
<member><xref linkend="sql-createpublication"/></member>
|
|
|
|
|
<member><xref linkend="sql-alterpublication"/></member>
|
2017-01-19 18:00:00 +01:00
|
|
|
</simplelist>
|
|
|
|
|
</refsect1>
|
|
|
|
|
</refentry>
|
