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>'
|
2021-06-25 09:51:24 +02:00
|
|
|
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> SET PUBLICATION <replaceable class="parameter">publication_name</replaceable> [, ...] [ WITH ( <replaceable class="parameter">publication_option</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ]
|
|
|
|
|
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> ADD PUBLICATION <replaceable class="parameter">publication_name</replaceable> [, ...] [ WITH ( <replaceable class="parameter">publication_option</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ]
|
|
|
|
|
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> DROP PUBLICATION <replaceable class="parameter">publication_name</replaceable> [, ...] [ WITH ( <replaceable class="parameter">publication_option</replaceable> [= <replaceable class="parameter">value</replaceable>] [, ... ] ) ]
|
2017-10-09 04:00:57 +02:00
|
|
|
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>] [, ... ] )
|
Add ALTER SUBSCRIPTION ... SKIP.
This feature allows skipping the transaction on subscriber nodes.
If incoming change violates any constraint, logical replication stops
until it's resolved. Currently, users need to either manually resolve the
conflict by updating a subscriber-side database or by using function
pg_replication_origin_advance() to skip the conflicting transaction. This
commit introduces a simpler way to skip the conflicting transactions.
The user can specify LSN by ALTER SUBSCRIPTION ... SKIP (lsn = XXX),
which allows the apply worker to skip the transaction finished at
specified LSN. The apply worker skips all data modification changes within
the transaction.
Author: Masahiko Sawada
Reviewed-by: Takamichi Osumi, Hou Zhijie, Peter Eisentraut, Amit Kapila, Shi Yu, Vignesh C, Greg Nancarrow, Haiying Tang, Euler Taveira
Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2022-03-22 02:41:19 +01:00
|
|
|
ALTER SUBSCRIPTION <replaceable class="parameter">name</replaceable> SKIP ( <replaceable class="parameter">skip_option</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>.
|
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 rename a subscription or alter the owner, you must have
|
|
|
|
|
<literal>CREATE</literal> permission on the database. In addition,
|
|
|
|
|
to alter the owner, you must be able to <literal>SET ROLE</literal> to the
|
|
|
|
|
new owning role. If the subscription has
|
|
|
|
|
<literal>password_required=false</literal>, only superusers can modify it.
|
2017-01-19 18:00:00 +01:00
|
|
|
</para>
|
2021-09-13 20:27:02 +02:00
|
|
|
|
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>
|
2021-09-13 20:27:02 +02:00
|
|
|
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>
|
2024-04-23 08:44:57 +02:00
|
|
|
Commands <command>ALTER SUBSCRIPTION ... REFRESH PUBLICATION</command>,
|
2021-09-29 04:56:13 +02:00
|
|
|
<command>ALTER SUBSCRIPTION ... {SET|ADD|DROP} PUBLICATION ...</command>
|
2024-04-23 08:44:57 +02:00
|
|
|
with <literal>refresh</literal> option as <literal>true</literal> and
|
|
|
|
|
<command>ALTER SUBSCRIPTION ... SET (failover = on|off)</command>
|
|
|
|
|
cannot be executed inside a transaction block.
|
Add support for prepared transactions to built-in logical replication.
To add support for streaming transactions at prepare time into the
built-in logical replication, we need to do the following things:
* Modify the output plugin (pgoutput) to implement the new two-phase API
callbacks, by leveraging the extended replication protocol.
* Modify the replication apply worker, to properly handle two-phase
transactions by replaying them on prepare.
* Add a new SUBSCRIPTION option "two_phase" to allow users to enable
two-phase transactions. We enable the two_phase once the initial data sync
is over.
We however must explicitly disable replication of two-phase transactions
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 know
where to send the data anyway.
The streaming option is not allowed with this new two_phase option. This
can be done as a separate patch.
We don't allow to toggle two_phase option of a subscription because it can
lead to an inconsistent replica. For the same reason, we don't allow to
refresh the publication once the two_phase is enabled for a subscription
unless copy_data option is false.
Author: Peter Smith, Ajin Cherian and Amit Kapila based on previous work by Nikhil Sontakke and Stas Kelvich
Reviewed-by: Amit Kapila, Sawada Masahiko, Vignesh C, Dilip Kumar, Takamichi Osumi, Greg Nancarrow
Tested-By: Haiying Tang
Discussion: https://postgr.es/m/02DA5F5E-CECE-4D9C-8B4B-418077E2C010@postgrespro.ru
Discussion: https://postgr.es/m/CAA4eK1+opiV4aFTmWWUF9h_32=HfPOW9vZASHarT0UA5oBrtGw@mail.gmail.com
2021-07-14 04:03:50 +02:00
|
|
|
|
|
|
|
|
These commands also cannot be executed when the subscription has
|
2023-10-30 06:16:31 +01:00
|
|
|
<link linkend="sql-createsubscription-params-with-two-phase"><literal>two_phase</literal></link>
|
2023-03-29 06:28:14 +02:00
|
|
|
commit enabled, unless
|
2023-10-30 06:16:31 +01:00
|
|
|
<link linkend="sql-createsubscription-params-with-copy-data"><literal>copy_data</literal></link>
|
2023-03-29 06:28:14 +02:00
|
|
|
is <literal>false</literal>. See column <structfield>subtwophasestate</structfield>
|
|
|
|
|
of <link linkend="catalog-pg-subscription"><structname>pg_subscription</structname></link>
|
2021-09-13 20:27:02 +02:00
|
|
|
to know the actual two-phase state.
|
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>
|
2017-01-19 18:00:00 +01:00
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
|
<title>Parameters</title>
|
|
|
|
|
|
|
|
|
|
<variablelist>
|
2023-10-13 08:43:46 +02:00
|
|
|
<varlistentry id="sql-altersubscription-params-name">
|
2017-01-19 18:00:00 +01:00
|
|
|
<term><replaceable class="parameter">name</replaceable></term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
The name of a subscription whose properties are to be altered.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2023-10-13 08:43:46 +02:00
|
|
|
<varlistentry id="sql-altersubscription-params-connection">
|
2017-01-19 18:00:00 +01:00
|
|
|
<term><literal>CONNECTION '<replaceable class="parameter">conninfo</replaceable>'</literal></term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
2021-09-13 20:27:02 +02:00
|
|
|
This clause replaces the connection string 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>
|
|
|
|
|
|
2023-10-13 08:43:46 +02:00
|
|
|
<varlistentry id="sql-altersubscription-params-setadddrop-publication">
|
2017-03-23 13:36:36 +01:00
|
|
|
<term><literal>SET PUBLICATION <replaceable class="parameter">publication_name</replaceable></literal></term>
|
2021-04-06 10:44:26 +02:00
|
|
|
<term><literal>ADD PUBLICATION <replaceable class="parameter">publication_name</replaceable></literal></term>
|
|
|
|
|
<term><literal>DROP PUBLICATION <replaceable class="parameter">publication_name</replaceable></literal></term>
|
2017-03-23 13:36:36 +01:00
|
|
|
<listitem>
|
|
|
|
|
<para>
|
2021-09-13 20:27:02 +02:00
|
|
|
These forms change the list of subscribed publications.
|
|
|
|
|
<literal>SET</literal>
|
2021-04-06 10:44:26 +02:00
|
|
|
replaces the entire list of publications with a new list,
|
2021-06-25 09:51:24 +02:00
|
|
|
<literal>ADD</literal> adds additional publications to the list of
|
|
|
|
|
publications, and <literal>DROP</literal> removes the publications from
|
2022-03-31 04:54:19 +02:00
|
|
|
the list of publications. We allow non-existent publications to be
|
|
|
|
|
specified in <literal>ADD</literal> and <literal>SET</literal> variants
|
|
|
|
|
so that users can add those later. See <xref linkend="sql-createsubscription"/>
|
2021-06-25 09:51:24 +02:00
|
|
|
for more information. By default, this command will also act like
|
2021-08-24 04:55:21 +02:00
|
|
|
<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>
|
2021-06-25 09:51:24 +02:00
|
|
|
<replaceable>publication_option</replaceable> specifies additional
|
2017-06-06 03:37:00 +02:00
|
|
|
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>
|
|
|
|
|
|
2021-09-15 09:54:45 +02:00
|
|
|
Additionally, the options described under
|
|
|
|
|
<literal>REFRESH PUBLICATION</literal> may be specified, to control the
|
|
|
|
|
implicit refresh operation.
|
2017-03-23 13:36:36 +01:00
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2023-10-13 08:43:46 +02:00
|
|
|
<varlistentry id="sql-altersubscription-params-refresh-publication">
|
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
|
2022-04-07 18:13:13 +02:00
|
|
|
replication of tables that were added to the subscribed-to publications
|
2023-10-13 08:43:46 +02:00
|
|
|
since <link linkend="sql-createsubscription">
|
|
|
|
|
<command>CREATE SUBSCRIPTION</command></link> or
|
2021-09-13 20:27:02 +02:00
|
|
|
the last invocation of <command>REFRESH PUBLICATION</command>.
|
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>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>
|
2021-09-13 20:27:02 +02:00
|
|
|
Specifies whether to copy pre-existing data in the publications
|
|
|
|
|
that are being subscribed to when the replication starts.
|
Allow specifying row filters for logical replication of tables.
This feature adds row filtering for publication tables. When a publication
is defined or modified, an optional WHERE clause can be specified. Rows
that don't satisfy this WHERE clause will be filtered out. This allows a
set of tables to be partially replicated. The row filter is per table. A
new row filter can be added simply by specifying a WHERE clause after the
table name. The WHERE clause must be enclosed by parentheses.
The row filter WHERE clause for a table added to a publication that
publishes UPDATE and/or DELETE operations must contain only columns that
are covered by REPLICA IDENTITY. The row filter WHERE clause for a table
added to a publication that publishes INSERT can use any column. If the
row filter evaluates to NULL, it is regarded as "false". The WHERE clause
only allows simple expressions that don't have user-defined functions,
user-defined operators, user-defined types, user-defined collations,
non-immutable built-in functions, or references to system columns. These
restrictions could be addressed in the future.
If you choose to do the initial table synchronization, only data that
satisfies the row filters is copied to the subscriber. If the subscription
has several publications in which a table has been published with
different WHERE clauses, rows that satisfy ANY of the expressions will be
copied. If a subscriber is a pre-15 version, the initial table
synchronization won't use row filters even if they are defined in the
publisher.
The row filters are applied before publishing the changes. If the
subscription has several publications in which the same table has been
published with different filters (for the same publish operation), those
expressions get OR'ed together so that rows satisfying any of the
expressions will be replicated.
This means all the other filters become redundant if (a) one of the
publications have no filter at all, (b) one of the publications was
created using FOR ALL TABLES, (c) one of the publications was created
using FOR ALL TABLES IN SCHEMA and the table belongs to that same schema.
If your publication contains a partitioned table, the publication
parameter publish_via_partition_root determines if it uses the partition's
row filter (if the parameter is false, the default) or the root
partitioned table's row filter.
Psql commands \dRp+ and \d <table-name> will display any row filters.
Author: Hou Zhijie, Euler Taveira, Peter Smith, Ajin Cherian
Reviewed-by: Greg Nancarrow, Haiying Tang, Amit Kapila, Tomas Vondra, Dilip Kumar, Vignesh C, Alvaro Herrera, Andres Freund, Wei Wang
Discussion: https://www.postgresql.org/message-id/flat/CAHE3wggb715X%2BmK_DitLXF25B%3DjE6xyNCH4YOwM860JR7HarGQ%40mail.gmail.com
2022-02-22 03:24:12 +01:00
|
|
|
The default is <literal>true</literal>.
|
|
|
|
|
</para>
|
|
|
|
|
<para>
|
2022-04-07 18:13:13 +02:00
|
|
|
Previously subscribed tables are not copied, even if a table's row
|
|
|
|
|
filter <literal>WHERE</literal> clause has since been modified.
|
2017-05-12 14:57:01 +02:00
|
|
|
</para>
|
2022-09-08 03:24:13 +02:00
|
|
|
<para>
|
|
|
|
|
See <xref linkend="sql-createsubscription-notes"/> for details of
|
|
|
|
|
how <literal>copy_data = true</literal> can interact with the
|
2023-10-30 06:16:31 +01:00
|
|
|
<link linkend="sql-createsubscription-params-with-origin"><literal>origin</literal></link>
|
2023-03-29 06:28:14 +02:00
|
|
|
parameter.
|
2022-09-08 03:24:13 +02:00
|
|
|
</para>
|
2023-03-23 04:15:51 +01:00
|
|
|
<para>
|
2023-03-29 06:28:14 +02:00
|
|
|
See the
|
2023-10-30 06:16:31 +01:00
|
|
|
<link linkend="sql-createsubscription-params-with-binary"><literal>binary</literal></link>
|
2023-03-29 06:28:14 +02:00
|
|
|
parameter of <command>CREATE SUBSCRIPTION</command> for details about
|
|
|
|
|
copying pre-existing data in binary format.
|
2023-03-23 04:15:51 +01:00
|
|
|
</para>
|
2017-05-12 14:57:01 +02:00
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
2020-06-07 14:54:28 +02:00
|
|
|
</variablelist></para>
|
2017-03-23 13:36:36 +01:00
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2023-10-13 08:43:46 +02:00
|
|
|
<varlistentry id="sql-altersubscription-params-enable">
|
2017-01-19 18:00:00 +01:00
|
|
|
<term><literal>ENABLE</literal></term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
2021-09-13 20:27:02 +02:00
|
|
|
Enables a previously disabled subscription, starting the logical
|
|
|
|
|
replication worker at the end of the transaction.
|
2017-01-19 18:00:00 +01:00
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2023-10-13 08:43:46 +02:00
|
|
|
<varlistentry id="sql-altersubscription-params-disable">
|
2017-01-19 18:00:00 +01:00
|
|
|
<term><literal>DISABLE</literal></term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
2021-09-13 20:27:02 +02:00
|
|
|
Disables a running subscription, stopping the logical replication
|
|
|
|
|
worker at the end of the transaction.
|
2017-01-19 18:00:00 +01:00
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
2017-03-23 13:36:36 +01:00
|
|
|
|
2023-10-13 08:43:46 +02:00
|
|
|
<varlistentry id="sql-altersubscription-params-set">
|
2017-05-12 14:57:01 +02:00
|
|
|
<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
|
2023-03-29 06:28:14 +02:00
|
|
|
information. The parameters that can be altered are
|
2023-10-30 06:16:31 +01:00
|
|
|
<link linkend="sql-createsubscription-params-with-slot-name"><literal>slot_name</literal></link>,
|
|
|
|
|
<link linkend="sql-createsubscription-params-with-synchronous-commit"><literal>synchronous_commit</literal></link>,
|
|
|
|
|
<link linkend="sql-createsubscription-params-with-binary"><literal>binary</literal></link>,
|
|
|
|
|
<link linkend="sql-createsubscription-params-with-streaming"><literal>streaming</literal></link>,
|
|
|
|
|
<link linkend="sql-createsubscription-params-with-disable-on-error"><literal>disable_on_error</literal></link>,
|
|
|
|
|
<link linkend="sql-createsubscription-params-with-password-required"><literal>password_required</literal></link>,
|
Add a failover option to subscriptions.
This commit introduces a new subscription option named 'failover', which
provides users with the ability to set the failover property of the
replication slot on the publisher when creating or altering a
subscription.
This uses the replication commands introduced by commit 7329240437 to
enable the failover option for a logical replication slot.
If the failover option is set to true, the associated replication slots
(i.e. the main slot and the table sync slots) in the upstream database are
enabled to be synchronized to the standbys. Note that the capability to
sync the replication slots will be added in subsequent commits.
Thanks to Masahiko Sawada for the design inputs.
Author: Shveta Malik, Hou Zhijie, Ajin Cherian
Reviewed-by: Peter Smith, Bertrand Drouvot, Dilip Kumar, Masahiko Sawada, Nisha Moond, Kuroda Hayato, Amit Kapila
Discussion: https://postgr.es/m/514f6f2f-6833-4539-39f1-96cd1e011f23@enterprisedb.com
2024-01-30 12:01:09 +01:00
|
|
|
<link linkend="sql-createsubscription-params-with-run-as-owner"><literal>run_as_owner</literal></link>,
|
|
|
|
|
<link linkend="sql-createsubscription-params-with-origin"><literal>origin</literal></link>, and
|
|
|
|
|
<link linkend="sql-createsubscription-params-with-failover"><literal>failover</literal></link>.
|
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
|
|
|
Only a superuser can set <literal>password_required = false</literal>.
|
2017-05-12 14:57:01 +02:00
|
|
|
</para>
|
Add a failover option to subscriptions.
This commit introduces a new subscription option named 'failover', which
provides users with the ability to set the failover property of the
replication slot on the publisher when creating or altering a
subscription.
This uses the replication commands introduced by commit 7329240437 to
enable the failover option for a logical replication slot.
If the failover option is set to true, the associated replication slots
(i.e. the main slot and the table sync slots) in the upstream database are
enabled to be synchronized to the standbys. Note that the capability to
sync the replication slots will be added in subsequent commits.
Thanks to Masahiko Sawada for the design inputs.
Author: Shveta Malik, Hou Zhijie, Ajin Cherian
Reviewed-by: Peter Smith, Bertrand Drouvot, Dilip Kumar, Masahiko Sawada, Nisha Moond, Kuroda Hayato, Amit Kapila
Discussion: https://postgr.es/m/514f6f2f-6833-4539-39f1-96cd1e011f23@enterprisedb.com
2024-01-30 12:01:09 +01:00
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
When altering the
|
|
|
|
|
<link linkend="sql-createsubscription-params-with-slot-name"><literal>slot_name</literal></link>,
|
2024-03-11 05:03:04 +01:00
|
|
|
the <literal>failover</literal> and <literal>two_phase</literal> property
|
|
|
|
|
values of the named slot may differ from the counterpart
|
Add a failover option to subscriptions.
This commit introduces a new subscription option named 'failover', which
provides users with the ability to set the failover property of the
replication slot on the publisher when creating or altering a
subscription.
This uses the replication commands introduced by commit 7329240437 to
enable the failover option for a logical replication slot.
If the failover option is set to true, the associated replication slots
(i.e. the main slot and the table sync slots) in the upstream database are
enabled to be synchronized to the standbys. Note that the capability to
sync the replication slots will be added in subsequent commits.
Thanks to Masahiko Sawada for the design inputs.
Author: Shveta Malik, Hou Zhijie, Ajin Cherian
Reviewed-by: Peter Smith, Bertrand Drouvot, Dilip Kumar, Masahiko Sawada, Nisha Moond, Kuroda Hayato, Amit Kapila
Discussion: https://postgr.es/m/514f6f2f-6833-4539-39f1-96cd1e011f23@enterprisedb.com
2024-01-30 12:01:09 +01:00
|
|
|
<link linkend="sql-createsubscription-params-with-failover"><literal>failover</literal></link>
|
2024-03-11 05:03:04 +01:00
|
|
|
and <link linkend="sql-createsubscription-params-with-two-phase"><literal>two_phase</literal></link>
|
|
|
|
|
parameters specified in the subscription. When creating the slot, ensure
|
|
|
|
|
the slot properties <literal>failover</literal> and <literal>two_phase</literal>
|
|
|
|
|
match their counterpart parameters of the subscription.
|
|
|
|
|
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
|
Add a failover option to subscriptions.
This commit introduces a new subscription option named 'failover', which
provides users with the ability to set the failover property of the
replication slot on the publisher when creating or altering a
subscription.
This uses the replication commands introduced by commit 7329240437 to
enable the failover option for a logical replication slot.
If the failover option is set to true, the associated replication slots
(i.e. the main slot and the table sync slots) in the upstream database are
enabled to be synchronized to the standbys. Note that the capability to
sync the replication slots will be added in subsequent commits.
Thanks to Masahiko Sawada for the design inputs.
Author: Shveta Malik, Hou Zhijie, Ajin Cherian
Reviewed-by: Peter Smith, Bertrand Drouvot, Dilip Kumar, Masahiko Sawada, Nisha Moond, Kuroda Hayato, Amit Kapila
Discussion: https://postgr.es/m/514f6f2f-6833-4539-39f1-96cd1e011f23@enterprisedb.com
2024-01-30 12:01:09 +01:00
|
|
|
synced to the standbys even when the subscription's
|
|
|
|
|
<link linkend="sql-createsubscription-params-with-failover"><literal>failover</literal></link>
|
|
|
|
|
option is disabled or could be disabled for sync
|
|
|
|
|
even when the subscription's
|
|
|
|
|
<link linkend="sql-createsubscription-params-with-failover"><literal>failover</literal></link>
|
|
|
|
|
option is enabled.
|
|
|
|
|
</para>
|
2017-05-12 14:57:01 +02:00
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2023-10-13 08:43:46 +02:00
|
|
|
<varlistentry id="sql-altersubscription-params-skip">
|
Add ALTER SUBSCRIPTION ... SKIP.
This feature allows skipping the transaction on subscriber nodes.
If incoming change violates any constraint, logical replication stops
until it's resolved. Currently, users need to either manually resolve the
conflict by updating a subscriber-side database or by using function
pg_replication_origin_advance() to skip the conflicting transaction. This
commit introduces a simpler way to skip the conflicting transactions.
The user can specify LSN by ALTER SUBSCRIPTION ... SKIP (lsn = XXX),
which allows the apply worker to skip the transaction finished at
specified LSN. The apply worker skips all data modification changes within
the transaction.
Author: Masahiko Sawada
Reviewed-by: Takamichi Osumi, Hou Zhijie, Peter Eisentraut, Amit Kapila, Shi Yu, Vignesh C, Greg Nancarrow, Haiying Tang, Euler Taveira
Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2022-03-22 02:41:19 +01:00
|
|
|
<term><literal>SKIP ( <replaceable class="parameter">skip_option</replaceable> = <replaceable class="parameter">value</replaceable> )</literal></term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Skips applying all changes of the remote transaction. If incoming data
|
|
|
|
|
violates any constraints, logical replication will stop until it is
|
2022-04-12 10:44:32 +02:00
|
|
|
resolved. By using the <command>ALTER SUBSCRIPTION ... SKIP</command> command,
|
Add ALTER SUBSCRIPTION ... SKIP.
This feature allows skipping the transaction on subscriber nodes.
If incoming change violates any constraint, logical replication stops
until it's resolved. Currently, users need to either manually resolve the
conflict by updating a subscriber-side database or by using function
pg_replication_origin_advance() to skip the conflicting transaction. This
commit introduces a simpler way to skip the conflicting transactions.
The user can specify LSN by ALTER SUBSCRIPTION ... SKIP (lsn = XXX),
which allows the apply worker to skip the transaction finished at
specified LSN. The apply worker skips all data modification changes within
the transaction.
Author: Masahiko Sawada
Reviewed-by: Takamichi Osumi, Hou Zhijie, Peter Eisentraut, Amit Kapila, Shi Yu, Vignesh C, Greg Nancarrow, Haiying Tang, Euler Taveira
Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2022-03-22 02:41:19 +01:00
|
|
|
the logical replication worker skips all data modification changes within
|
|
|
|
|
the transaction. This option has no effect on the transactions that are
|
2023-03-29 06:28:14 +02:00
|
|
|
already prepared by enabling
|
2023-10-30 06:16:31 +01:00
|
|
|
<link linkend="sql-createsubscription-params-with-two-phase"><literal>two_phase</literal></link>
|
2023-03-29 06:28:14 +02:00
|
|
|
on the subscriber.
|
2022-04-12 10:44:32 +02:00
|
|
|
After the logical replication worker successfully skips the transaction or
|
|
|
|
|
finishes a transaction, the LSN (stored in
|
Add ALTER SUBSCRIPTION ... SKIP.
This feature allows skipping the transaction on subscriber nodes.
If incoming change violates any constraint, logical replication stops
until it's resolved. Currently, users need to either manually resolve the
conflict by updating a subscriber-side database or by using function
pg_replication_origin_advance() to skip the conflicting transaction. This
commit introduces a simpler way to skip the conflicting transactions.
The user can specify LSN by ALTER SUBSCRIPTION ... SKIP (lsn = XXX),
which allows the apply worker to skip the transaction finished at
specified LSN. The apply worker skips all data modification changes within
the transaction.
Author: Masahiko Sawada
Reviewed-by: Takamichi Osumi, Hou Zhijie, Peter Eisentraut, Amit Kapila, Shi Yu, Vignesh C, Greg Nancarrow, Haiying Tang, Euler Taveira
Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2022-03-22 02:41:19 +01:00
|
|
|
<structname>pg_subscription</structname>.<structfield>subskiplsn</structfield>)
|
|
|
|
|
is cleared. See <xref linkend="logical-replication-conflicts"/> for
|
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
|
|
|
the details of logical replication conflicts.
|
Add ALTER SUBSCRIPTION ... SKIP.
This feature allows skipping the transaction on subscriber nodes.
If incoming change violates any constraint, logical replication stops
until it's resolved. Currently, users need to either manually resolve the
conflict by updating a subscriber-side database or by using function
pg_replication_origin_advance() to skip the conflicting transaction. This
commit introduces a simpler way to skip the conflicting transactions.
The user can specify LSN by ALTER SUBSCRIPTION ... SKIP (lsn = XXX),
which allows the apply worker to skip the transaction finished at
specified LSN. The apply worker skips all data modification changes within
the transaction.
Author: Masahiko Sawada
Reviewed-by: Takamichi Osumi, Hou Zhijie, Peter Eisentraut, Amit Kapila, Shi Yu, Vignesh C, Greg Nancarrow, Haiying Tang, Euler Taveira
Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2022-03-22 02:41:19 +01:00
|
|
|
</para>
|
|
|
|
|
|
|
|
|
|
<para>
|
|
|
|
|
<replaceable>skip_option</replaceable> specifies options for this operation.
|
|
|
|
|
The supported option is:
|
|
|
|
|
|
|
|
|
|
<variablelist>
|
|
|
|
|
<varlistentry>
|
|
|
|
|
<term><literal>lsn</literal> (<type>pg_lsn</type>)</term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
Specifies the finish LSN of the remote transaction whose changes
|
|
|
|
|
are to be skipped by the logical replication worker. The finish LSN
|
|
|
|
|
is the LSN at which the transaction is either committed or prepared.
|
2022-04-12 10:44:32 +02:00
|
|
|
Skipping individual subtransactions is not supported. Setting
|
Add ALTER SUBSCRIPTION ... SKIP.
This feature allows skipping the transaction on subscriber nodes.
If incoming change violates any constraint, logical replication stops
until it's resolved. Currently, users need to either manually resolve the
conflict by updating a subscriber-side database or by using function
pg_replication_origin_advance() to skip the conflicting transaction. This
commit introduces a simpler way to skip the conflicting transactions.
The user can specify LSN by ALTER SUBSCRIPTION ... SKIP (lsn = XXX),
which allows the apply worker to skip the transaction finished at
specified LSN. The apply worker skips all data modification changes within
the transaction.
Author: Masahiko Sawada
Reviewed-by: Takamichi Osumi, Hou Zhijie, Peter Eisentraut, Amit Kapila, Shi Yu, Vignesh C, Greg Nancarrow, Haiying Tang, Euler Taveira
Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2022-03-22 02:41:19 +01:00
|
|
|
<literal>NONE</literal> resets the LSN.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
2022-04-07 18:23:28 +02:00
|
|
|
</variablelist></para>
|
Add ALTER SUBSCRIPTION ... SKIP.
This feature allows skipping the transaction on subscriber nodes.
If incoming change violates any constraint, logical replication stops
until it's resolved. Currently, users need to either manually resolve the
conflict by updating a subscriber-side database or by using function
pg_replication_origin_advance() to skip the conflicting transaction. This
commit introduces a simpler way to skip the conflicting transactions.
The user can specify LSN by ALTER SUBSCRIPTION ... SKIP (lsn = XXX),
which allows the apply worker to skip the transaction finished at
specified LSN. The apply worker skips all data modification changes within
the transaction.
Author: Masahiko Sawada
Reviewed-by: Takamichi Osumi, Hou Zhijie, Peter Eisentraut, Amit Kapila, Shi Yu, Vignesh C, Greg Nancarrow, Haiying Tang, Euler Taveira
Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com
2022-03-22 02:41:19 +01:00
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2023-10-13 08:43:46 +02:00
|
|
|
<varlistentry id="sql-altersubscription-params-new-owner">
|
2017-05-02 21:29:30 +02:00
|
|
|
<term><replaceable class="parameter">new_owner</replaceable></term>
|
|
|
|
|
<listitem>
|
|
|
|
|
<para>
|
|
|
|
|
The user name of the new owner of the subscription.
|
|
|
|
|
</para>
|
|
|
|
|
</listitem>
|
|
|
|
|
</varlistentry>
|
|
|
|
|
|
2023-10-13 08:43:46 +02:00
|
|
|
<varlistentry id="sql-altersubscription-params-new-name">
|
2017-05-02 21:29:30 +02:00
|
|
|
<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>
|
2023-01-30 17:59:37 +01:00
|
|
|
|
|
|
|
|
<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>
|
2017-01-19 18:00:00 +01:00
|
|
|
</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>
|
