Компания Postgres Professional

ALTER SUBSCRIPTION
Пред.	Наверх	Команды SQL	Начало	След.

ALTER SUBSCRIPTION

ALTER SUBSCRIPTION — изменить определение подписки

Синтаксис

ALTER SUBSCRIPTION имя CONNECTION 'строка_подключения'
ALTER SUBSCRIPTION имя SET PUBLICATION имя_публикации [, ...] [ WITH ( параметр_публикации [= значение] [, ... ] ) ]
ALTER SUBSCRIPTION имя ADD PUBLICATION имя_публикации [, ...] [ WITH ( параметр_публикации [= значение] [, ... ] ) ]
ALTER SUBSCRIPTION имя DROP PUBLICATION имя_публикации [, ...] [ WITH ( параметр_публикации [= значение] [, ... ] ) ]
ALTER SUBSCRIPTION имя REFRESH PUBLICATION [ WITH ( параметр_обновления [= значение] [, ... ] ) ]
ALTER SUBSCRIPTION имя ENABLE
ALTER SUBSCRIPTION имя DISABLE
ALTER SUBSCRIPTION имя SET ( параметр_подписки [= значение] [, ... ] )
ALTER SUBSCRIPTION имя SKIP ( параметр_пропуска = значение )
ALTER SUBSCRIPTION имя OWNER TO { новый_владелец | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER SUBSCRIPTION имя RENAME TO новое_имя

Описание

ALTER SUBSCRIPTION может менять многие свойства подписки, которые могут задаваться в CREATE SUBSCRIPTION.

Чтобы выполнить ALTER SUBSCRIPTION для подписки, нужно быть её владельцем. Чтобы переименовать подписку или сменить владельца, необходимо иметь право CREATE в базе данных. Кроме того, чтобы сменить владельца, необходимо иметь право SET ROLE для новой роли-владельца. Если для подписки задано password_required=false, изменять её могут только суперпользователи.

При обновлении подписки производится удаление отношений, которые были из неё исключены, а также удаление слотов синхронизации этих таблиц, если таковые имеются. Эти слоты необходимо удалять, чтобы были освобождены ресурсы, выделенные для данной подписки на удалённом сервере. Если по причине сбоя в сети или какой-то другой ошибки Postgres Pro не сможет удалить эти слоты, выполнение команды будет прервано ошибкой. Для разрешения такой ситуации можно либо попробовать повторить эту операцию, либо разорвать связь слота с подпиской и удалить подписку, выполнив DROP SUBSCRIPTION.

Команды ALTER SUBSCRIPTION ... REFRESH PUBLICATION, ALTER SUBSCRIPTION ... {SET|ADD|DROP} PUBLICATION ... с параметром refresh, равным true, ALTER SUBSCRIPTION ... SET (failover = true|false) и ALTER SUBSCRIPTION ... SET (two_phase = false) не могут выполняться в блоке транзакции.

Команды ALTER SUBSCRIPTION ... REFRESH PUBLICATION и ALTER SUBSCRIPTION ... {SET|ADD|DROP} PUBLICATION ... с параметром refresh, равным true, также не могут выполняться, если для подписки включён режим two_phase, за исключением случая, когда copy_data равен false. Состояние режима двухфазной фиксации показывается в столбце subtwophasestate каталога pg_subscription.

Параметры

имя #

Имя подписки, свойства которой изменяются.

CONNECTION 'строка_подключения' #

Это предложение заменяет строку соединения, изначально установленную командой CREATE SUBSCRIPTION. За дополнительными сведениями обратитесь к описанию этой команды.

SET PUBLICATION имя_публикации ADD PUBLICATION имя_публикации DROP PUBLICATION имя_публикации #

Изменяет список публикаций, на которые оформлена подписка. Предложение SET полностью заменяет один список публикаций другим, ADD добавляет публикации к списку публикаций, а DROP удаляет публикации из этого списка. В формах ADD и SET допускается указание несуществующих публикаций в расчёте на то, что они будут добавлены позже. За подробностями обратитесь к описанию CREATE SUBSCRIPTION. По умолчанию эта команда также выполняет действие REFRESH PUBLICATION.

В указании параметр_публикации задаются дополнительные свойства операции. Поддерживаются следующие параметры:

refresh (boolean): Со значением false данная команда не будет обновлять информацию о таблицах. В этом случае следует выполнить REFRESH PUBLICATION отдельно. Значение по умолчанию — true.

Кроме того, здесь могут задаваться параметры, относящиеся к REFRESH PUBLICATION и управляющие неявной операцией обновления.

REFRESH PUBLICATION #

Считывает недостающую информацию о таблицах с публикующего сервера. В результате производится репликация таблиц, добавленных в публикации, на которые оформлена подписка, после CREATE SUBSCRIPTION или последнего вызова REFRESH PUBLICATION.

В указании параметр_обновления задаются дополнительные свойства операции обновления. Поддерживаются следующие параметры:

copy_data (boolean)

Определяет, должны ли копироваться уже существующие данные в публикациях, на которые оформляется подписка, когда начинается репликация. Значение по умолчанию — true.

Таблицы, входившие в подписку ранее, не копируются, даже если предложение WHERE фильтра строк таблицы изменилось с момента подписки.

Подробнее взаимодействие copy_data = true с параметром origin описано в Замечания.

Чтобы получить дополнительные сведения о копировании уже существующих данных в двоичном формате, обратитесь к описанию параметра binary команды CREATE SUBSCRIPTION.

ENABLE #

Включает ранее отключённую подписку, запуская процесс логической репликации в конце транзакции.

DISABLE #

Отключает активную подписку, останавливая процесс логической репликации в конце транзакции.

SET ( параметр_подписки [= значение] [, ... ] ) #

Это предложение изменяет параметры, изначально установленные командой CREATE SUBSCRIPTION. За подробностями обратитесь к её описанию. Данное предложение позволяет изменить параметры slot_name, synchronous_commit, binary, streaming, disable_on_error, password_required, run_as_owner, origin, failover и two_phase. Указать password_required = false может только суперпользователь.

При изменении slot_name параметры failover и two_phase указанного слота могут отличаться от параметров failover и two_phase, указанных в подписке. При создании слота убедитесь, что значения слота в параметрах failover и two_phase совпадают с указанными в подписке, иначе слот на публикующем сервере может вести себя по-другому: например, слот на публикующем сервере может синхронизироваться с резервными серверами даже при выключенном в подписке параметре failover и не синхронизироваться даже при включённом в подписке параметре failover.

Параметры failover и two_phase можно изменять только тогда, когда подписка отключена.

При изменении значения параметра two_phase с true на false обслуживающий процесс выдаёт ошибку, если обнаружены подготовленные транзакции, созданные рабочим процессом логической репликации (когда для параметра two_phase ещё было задано true). В этом случае можно разрешить подготовленные транзакции на публикующем узле или вручную откатить их на подписчике, а затем повторить попытку. Транзакции, подготовленные рабочим процессом логической репликации для конкретной подписки, получают имена такого формата: «pg_gid_%u_%u» (параметры: идентификатор подписки oid, идентификатор удалённой транзакции xid). Чтобы завершить такие транзакции вручную, необходимо откатить все подготовленные транзакции с соответствующими идентификаторами подписок в именах. Чтобы найти нужные подготовленные транзакции, приложения могут проверить представление pg_prepared_xacts. После изменения значения параметра two_phase с true на false публикующий узел будет повторно реплицировать транзакции при их фиксации.

SKIP ( параметр_пропуска = значение ) #

Пропускает применение всех изменений удалённой транзакции. Если входящие данные нарушают какие-либо ограничения, логическая репликация будет остановлена, пока конфликты не будут разрешены. Когда выполняется команда ALTER SUBSCRIPTION ... SKIP, рабочий процесс логической репликации пропускает все изменения данных в транзакции. Этот параметр не влияет на транзакции, которые уже подготовлены на стороне подписчика (в результате действия режима two_phase). После того, как рабочий процесс логической репликации успешно пропускает транзакцию или транзакция завершается, номер LSN (хранящийся в pg_subscription.subskiplsn) очищается. Подробнее конфликты логической репликации описаны в Разделе 30.7.

Параметр_пропуска определяет свойства данной операции. Поддерживается следующий параметр:

lsn (pg_lsn): Указывает LSN завершения удалённой транзакции, изменения которой должны быть пропущены процессом логической репликации. LSN завершения — это LSN, с которым транзакция зафиксирована либо подготовлена. Пропуск отдельных подтранзакций не поддерживается. Значение NONE сбрасывает ранее установленный LSN.

новый_владелец #

Имя пользователя, назначаемого новым владельцем подписки.

новое_имя #

Новое имя подписки.

Если для параметра типа boolean опустить = значение, это равнозначно указанию значения TRUE.

Примеры

Изменение подписки, заключающееся в подписывании на публикацию insert_only:

ALTER SUBSCRIPTION mysub SET PUBLICATION insert_only;

Отключение (остановка) подписки:

ALTER SUBSCRIPTION mysub DISABLE;

Совместимость

ALTER SUBSCRIPTION является расширением Postgres Pro.

См. также

CREATE SUBSCRIPTION, DROP SUBSCRIPTION, CREATE PUBLICATION, ALTER PUBLICATION

Пред.	Наверх	След.
ALTER STATISTICS	Начало	ALTER SYSTEM

ALTER SUBSCRIPTION
Prev	Up	SQL Commands	Home	Next

ALTER SUBSCRIPTION

ALTER SUBSCRIPTION — change the definition of a subscription

Synopsis

ALTER SUBSCRIPTION name CONNECTION 'conninfo'
ALTER SUBSCRIPTION name SET PUBLICATION publication_name [, ...] [ WITH ( publication_option [= value] [, ... ] ) ]
ALTER SUBSCRIPTION name ADD PUBLICATION publication_name [, ...] [ WITH ( publication_option [= value] [, ... ] ) ]
ALTER SUBSCRIPTION name DROP PUBLICATION publication_name [, ...] [ WITH ( publication_option [= value] [, ... ] ) ]
ALTER SUBSCRIPTION name REFRESH PUBLICATION [ WITH ( refresh_option [= value] [, ... ] ) ]
ALTER SUBSCRIPTION name ENABLE
ALTER SUBSCRIPTION name DISABLE
ALTER SUBSCRIPTION name SET ( subscription_parameter [= value] [, ... ] )
ALTER SUBSCRIPTION name SKIP ( skip_option = value )
ALTER SUBSCRIPTION name OWNER TO { new_owner | CURRENT_ROLE | CURRENT_USER | SESSION_USER }
ALTER SUBSCRIPTION name RENAME TO new_name

Description

ALTER SUBSCRIPTION can change most of the subscription properties that can be specified in CREATE SUBSCRIPTION.

You must own the subscription to use ALTER SUBSCRIPTION. To rename a subscription or alter the owner, you must have CREATE permission on the database. In addition, to alter the owner, you must be able to SET ROLE to the new owning role. If the subscription has password_required=false, only superusers can modify it.

When refreshing a publication we remove the relations that are no longer 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 allocated for the subscription on the remote host are released. If due to network breakdown or some other error, Postgres Pro is unable to remove the slots, an error will be reported. To proceed in this situation, the user either needs to retry the operation or disassociate the slot from the subscription and drop the subscription as explained in DROP SUBSCRIPTION.

Commands ALTER SUBSCRIPTION ... REFRESH PUBLICATION, ALTER SUBSCRIPTION ... {SET|ADD|DROP} PUBLICATION ... with refresh option as true, ALTER SUBSCRIPTION ... SET (failover = true|false) and ALTER SUBSCRIPTION ... SET (two_phase = false) cannot be executed inside a transaction block.

Commands ALTER SUBSCRIPTION ... REFRESH PUBLICATION and ALTER SUBSCRIPTION ... {SET|ADD|DROP} PUBLICATION ... with refresh option as true also cannot be executed when the subscription has two_phase commit enabled, unless copy_data is false. See column subtwophasestate of pg_subscription to know the actual two-phase state.

Parameters

name #

The name of a subscription whose properties are to be altered.

CONNECTION 'conninfo' #

This clause replaces the connection string originally set by CREATE SUBSCRIPTION. See there for more information.

SET PUBLICATION publication_name ADD PUBLICATION publication_name DROP PUBLICATION publication_name #

These forms change the list of subscribed publications. SET replaces the entire list of publications with a new list, ADD adds additional publications to the list of publications, and DROP removes the publications from the list of publications. We allow non-existent publications to be specified in ADD and SET variants so that users can add those later. See CREATE SUBSCRIPTION for more information. By default, this command will also act like REFRESH PUBLICATION.

publication_option specifies additional options for this operation. The supported options are:

refresh (boolean): When false, the command will not try to refresh table information. REFRESH PUBLICATION should then be executed separately. The default is true.

Additionally, the options described under REFRESH PUBLICATION may be specified, to control the implicit refresh operation.

REFRESH PUBLICATION #

Fetch missing table information from publisher. This will start replication of tables that were added to the subscribed-to publications since CREATE SUBSCRIPTION or the last invocation of REFRESH PUBLICATION.

refresh_option specifies additional options for the refresh operation. The supported options are:

copy_data (boolean)

Specifies whether to copy pre-existing data in the publications that are being subscribed to when the replication starts. The default is true.

Previously subscribed tables are not copied, even if a table's row filter WHERE clause has since been modified.

See Notes for details of how copy_data = true can interact with the origin parameter.

See the binary parameter of CREATE SUBSCRIPTION for details about copying pre-existing data in binary format.

ENABLE #

Enables a previously disabled subscription, starting the logical replication worker at the end of the transaction.

DISABLE #

Disables a running subscription, stopping the logical replication worker at the end of the transaction.

SET ( subscription_parameter [= value] [, ... ] ) #

This clause alters parameters originally set by CREATE SUBSCRIPTION. See there for more information. The parameters that can be altered are slot_name, synchronous_commit, binary, streaming, disable_on_error, password_required, run_as_owner, origin, failover, and two_phase. Only a superuser can set password_required = false.

When altering the slot_name, the failover and two_phase property values of the named slot may differ from the counterpart failover and two_phase parameters specified in the subscription. When creating the slot, ensure the slot properties failover and two_phase 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 synced to the standbys even when the subscription's failover option is disabled or could be disabled for sync even when the subscription's failover option is enabled.

The failover and two_phase parameters can only be altered when the subscription is disabled.

When altering two_phase from true to false, the backend process reports an error if any prepared transactions done by the logical replication worker (from when two_phase parameter was still true) are found. You can resolve prepared transactions on the publisher node, or manually roll them back on the subscriber, and then try again. The transactions prepared by logical replication worker corresponding to a particular subscription have the following pattern: “pg_gid_%u_%u” (parameters: subscription oid, remote transaction id xid). To resolve such transactions manually, you need to roll back all the prepared transactions with corresponding subscription IDs in their names. Applications can check pg_prepared_xacts to find the required prepared transactions. After the two_phase option is changed from true to false, the publisher will replicate the transactions again when they are committed.

SKIP ( skip_option = value ) #

Skips applying all changes of the remote transaction. If incoming data violates any constraints, logical replication will stop until it is resolved. By using the ALTER SUBSCRIPTION ... SKIP command, the logical replication worker skips all data modification changes within the transaction. This option has no effect on the transactions that are already prepared by enabling two_phase on the subscriber. After the logical replication worker successfully skips the transaction or finishes a transaction, the LSN (stored in pg_subscription.subskiplsn) is cleared. See Section 30.7 for the details of logical replication conflicts.

skip_option specifies options for this operation. The supported option is:

lsn (pg_lsn): 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. Skipping individual subtransactions is not supported. Setting NONE resets the LSN.

new_owner #

The user name of the new owner of the subscription.

new_name #

The new name for the subscription.

When specifying a parameter of type boolean, the = value part can be omitted, which is equivalent to specifying TRUE.

Examples

Change the publication subscribed by a subscription to insert_only:

ALTER SUBSCRIPTION mysub SET PUBLICATION insert_only;

Disable (stop) the subscription:

ALTER SUBSCRIPTION mysub DISABLE;

Compatibility

ALTER SUBSCRIPTION is a Postgres Pro extension.

ALTER SUBSCRIPTION

Синтаксис

Описание

Параметры

Примеры

Совместимость

См. также

ALTER SUBSCRIPTION

Synopsis

Description

Parameters

Examples

Compatibility

See Also