ALTER SUBSCRIPTION

ALTER SUBSCRIPTION
Prev	Up	Comandos SQL	Home	Next

ALTER SUBSCRIPTION — cambiar la definición de una suscripción

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

Descripción

ALTER SUBSCRIPTION puede cambiar la mayoría de las propiedades de la suscripción que se pueden especificar en CREATE SUBSCRIPTION.

Debes ser el propietario de la suscripción para usar ALTER SUBSCRIPTION. Para renombrar una suscripción o cambiar su propietario, debes tener el permiso CREATE en la base de datos. Además, para cambiar el propietario, debes ser capaz de hacer SET ROLE al nuevo rol propietario. Si la suscripción tiene password_required=false, solo los superusuarios pueden modificarla.

Al actualizar una publicación, eliminamos las relaciones que ya no forman parte de la publicación y también eliminamos las ranuras (slots) de sincronización de tablas, si las hay. Es necesario eliminar estas ranuras para que se liberen los recursos asignados para la suscripción en el host remoto. Si debido a una caída de la red o algún otro error, PostgreSQL no puede eliminar las ranuras, se informará un error. Para proceder en esta situación, el usuario debe reintentar la operación o desasociar la ranura de la suscripción y eliminar la suscripción como se explica en DROP SUBSCRIPTION.

Los comandos ALTER SUBSCRIPTION ... REFRESH PUBLICATION, ALTER SUBSCRIPTION ... {SET|ADD|DROP} PUBLICATION ... con la opción refresh establecida en true, ALTER SUBSCRIPTION ... SET (failover = true|false) y ALTER SUBSCRIPTION ... SET (two_phase = false) no se pueden ejecutar dentro de un bloque de transacción.

Los comandos ALTER SUBSCRIPTION ... REFRESH PUBLICATION y ALTER SUBSCRIPTION ... {SET|ADD|DROP} PUBLICATION ... con la opción refresh como true tampoco se pueden ejecutar cuando la suscripción tiene habilitada la confirmación en dos fases (two_phase), a menos que copy_data sea false. Consulta la columna subtwophasestate de pg_subscription para conocer el estado real de la confirmación en dos fases.

Parámetros

name #

El nombre de una suscripción cuyas propiedades se van a modificar.

CONNECTION 'conninfo' #

Esta cláusula reemplaza la cadena de conexión establecida originalmente por CREATE SUBSCRIPTION. Consulta allí para obtener más información.

SET PUBLICATION publication_name ADD PUBLICATION publication_name DROP PUBLICATION publication_name #

Estas formas cambian la lista de publicaciones suscritas. SET reemplaza toda la lista de publicaciones con una nueva lista, ADD agrega publicaciones adicionales a la lista de publicaciones, y DROP elimina las publicaciones de la lista de publicaciones. Permitimos que se especifiquen publicaciones que no existen en las variantes ADD y SET para que los usuarios puedan agregarlas más tarde. Consulta CREATE SUBSCRIPTION para obtener más información. De forma predeterminada, este comando también actuará como REFRESH PUBLICATION.

publication_option especifica opciones adicionales para esta operación. Las opciones compatibles son:

refresh (boolean): Cuando es false, el comando no intentará actualizar la información de la tabla. En ese caso, REFRESH PUBLICATION debe ejecutarse por separado. El valor predeterminado es true.

Además, se pueden especificar las opciones descritas en REFRESH PUBLICATION para controlar la operación de actualización implícita.

REFRESH PUBLICATION #

Obtener del publicador la información de tabla faltante. Esto iniciará la replicación de las tablas que se agregaron a las publicaciones suscritas desde CREATE SUBSCRIPTION o desde la última invocación de REFRESH PUBLICATION.

refresh_option especifica opciones adicionales para la operación de actualización. Las opciones compatibles son:

copy_data (boolean)

Especifica si se deben copiar los datos preexistentes en las publicaciones a las que se está suscribiendo cuando se inicia la replicación. El valor predeterminado es true.

Las tablas suscritas anteriormente no se copian, incluso si la cláusula WHERE del filtro de filas de una tabla se ha modificado desde entonces.

Consulta Notas para obtener detalles sobre cómo copy_data = true puede interactuar con el parámetro origin.

Consulta el parámetro binary de CREATE SUBSCRIPTION para obtener detalles sobre la copia de datos preexistentes en formato binario.

ENABLE #

Habilita una suscripción previamente deshabilitada, iniciando el proceso trabajador (worker) de replicación lógica al final de la transacción.

DISABLE #

Deshabilita una suscripción activa, deteniendo el proceso trabajador de replicación lógica al final de la transacción.

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

Esta cláusula modifica los parámetros establecidos originalmente por CREATE SUBSCRIPTION. Consulta allí para obtener más información. Los parámetros que se pueden modificar son slot_name, synchronous_commit, binary, streaming, disable_on_error, password_required, run_as_owner, origin, failover, y two_phase. Solo un superusuario puede establecer password_required = false.

Al modificar el parámetro slot_name, los valores de las propiedades failover y two_phase de la ranura nombrada pueden diferir de los parámetros correspondientes failover y two_phase especificados en la suscripción. Al crear la ranura, asegúrate de que las propiedades de la ranura failover y two_phase coincidan con sus parámetros correspondientes de la suscripción. De lo contrario, la ranura en el publicador puede comportarse de manera diferente a lo que dicen estas opciones de suscripción: por ejemplo, la ranura en el publicador podría sincronizarse con las réplicas incluso cuando la opción failover de la suscripción esté deshabilitada, o podría deshabilitarse para la sincronización incluso cuando la opción failover de la suscripción esté habilitada.

Los parámetros failover y two_phase solo se pueden modificar cuando la suscripción está deshabilitada.

Al cambiar two_phase de true a false, el proceso del backend informa un error si se encuentra alguna transacción preparada realizada por el proceso trabajador de replicación lógica (de cuando el parámetro two_phase todavía era true). Puedes resolver las transacciones preparadas en el nodo publicador o revertirlas (roll back) manualmente en el suscriptor, y luego intentarlo de nuevo. Las transacciones preparadas por el proceso trabajador de replicación lógica que corresponden a una suscripción particular tienen el siguiente patrón: “pg_gid_%u_%u” (parámetros: oid de la suscripción, xid de la transacción remota). Para resolver tales transacciones manualmente, debes revertir todas las transacciones preparadas que contengan los ID de suscripción correspondientes en sus nombres. Las aplicaciones pueden consultar pg_prepared_xacts para encontrar las transacciones preparadas requeridas. Después de cambiar la opción two_phase de true a false, el publicador replicará las transacciones nuevamente cuando se confirmen.

SKIP ( skip_option = value ) #

Omite la aplicación de todos los cambios de la transacción remota. Si los datos entrantes violan alguna restricción, la replicación lógica se detendrá hasta que se resuelva. Al usar el comando ALTER SUBSCRIPTION ... SKIP, el proceso trabajador de replicación lógica omite todos los cambios de modificación de datos dentro de la transacción. Esta opción no tiene efecto en las transacciones que ya están preparadas al habilitar two_phase en el suscriptor. Después de que el proceso trabajador de replicación lógica omite con éxito la transacción o finaliza una transacción, se limpia el LSN (almacenado en pg_subscription.subskiplsn). Consulta Section 29.7 para obtener detalles sobre los conflictos de replicación lógica.

skip_option especifica opciones para esta operación. La opción compatible es:

lsn (pg_lsn): Especifica el LSN de finalización de la transacción remota cuyos cambios debe omitir el proceso trabajador de replicación lógica. El LSN de finalización es el LSN en el que la transacción se confirma o se prepara. No se admite la omisión de subtransacciones individuales. Establecer NONE restablece el LSN.

new_owner #

El nombre de usuario del nuevo propietario de la suscripción.

new_name #

El nuevo nombre para la suscripción.

Al especificar un parámetro de tipo boolean, se puede omitir la parte = value, lo cual es equivalente a especificar TRUE.

Ejemplos

Cambiar la publicación suscrita por una suscripción a insert_only:

ALTER SUBSCRIPTION mysub SET PUBLICATION insert_only;

Deshabilitar (detener) la suscripción:

ALTER SUBSCRIPTION mysub DISABLE;

Compatibilidad

ALTER SUBSCRIPTION es una extensión de PostgreSQL.

Véase también

CREATE SUBSCRIPTION, DROP SUBSCRIPTION, CREATE PUBLICATION, ALTER PUBLICATION