Node management interfaces ========================== You can add and remove nodes dynamically using the SQL interfaces. bdr.alter_node_group_option --------------------------- Modifies a PGD node group configuration. Synopsis ^^^^^^^^ .. code:: sql bdr.alter_node_group_option(node_group_name text, config_key text, config_value text) Parameters ^^^^^^^^^^ .. csv-table:: :header: Name,Description :widths: 10,30 :align: left :class: longtable `node_group_name`,Name of the group to change. `config_key`,Key of the option in the node group to change. `config_value`,New value to set for the given key. ``config_value`` is parsed into the data type appropriate for the option. The table shows the group options that can be changed using this function. .. csv-table:: :header: Name,Type,Description :widths: 12,10,25 :align: left :class: longtable `analytics_storage_format`,`text`,The columnar table format used by PGAA for the analytical data. Supported values are `iceberg` (default) or `delta`. `analytics_storage_location`,`text`,The PGFS path where the analytical data files are stored. Used primarily when writing directly to object storage via the PGAA extension. `analytics_write_catalog`,`text`,The name of the catalog service used by the PGAA extension to manage table metadata. `apply_delay`,`interval`,How long nodes wait to apply incoming changes. This option is useful mainly to set up a special subgroup with delayed subscriber-only nodes. Don't set this on groups that contain data nodes or on the top-level group. Default is `0s`. `apply_error_max_record_size`,`bigint`,"Maximum number of bytes of change data to record per failed transaction when using a `record_all_and_disable` or `record_all_and_skip` policy. If a transaction exceeds this limit, only the changes captured up to the limit are stored and a warning is logged. Default is `10485760` (10 MB)." `apply_error_max_retries`,`integer`,"Number of retry attempts before the error policy takes action. Applies to the `disable_after_retries`, `record_all_and_disable`, and `record_all_and_skip` policies. Default is `3`." `apply_error_max_skips`,`integer`,Maximum number of transactions the `record_all_and_skip` policy can skip before disabling the subscription. Set to `-1` or `NULL` for unlimited skips. Default is `NULL`. `apply_error_policy`,`text`,"How replication apply errors are handled for subscriptions in this group. Valid values are `keep_retrying` (retry indefinitely), `disable_after_retries` (retry up to `apply_error_max_retries` times, then disable the subscription), `record_all_and_disable` (record the entire transaction by replaying it in capture-only mode, then disable the subscription), and `record_all_and_skip` (record the entire transaction, skip it, and continue replicating). Default is `keep_retrying`." `check_constraints`,`boolean`,Whether the apply process checks the constraints when writing replicated data. We recommend keeping the default value or you risk data loss. Valid values are `on` or `off`. Default is `on`. `default_commit_scope`,`text`,"The commit scope to use by default, initially the `local` commit scope. This option applies only to the top-level node group. You can use individual rules for different origin groups of the same commit scope. See :ref:`Commit scope groups` for more details." `enable_fast_track_writer`,`boolean`,Enables an additional writer for all subscriptions to process prepared transactions generated by Quorum Commit. Required for correct functioning with Quorum Commit commit scopes. Automatically enabled when a Quorum Commit scope is set as `default_commit_scope`. Default is `off`. See :ref:`pg_upgrade ` . `enable_routing`,`boolean`,Where :ref:``Connection Manager` ` through the group write leader is enabled for a given group. Valid values are `on` or `off`. Default is `on` for subgroups and `off` for the cluster group. `enable_raft`,`boolean`,Whether group has its own Raft consensus. This option is necessary for setting `enable_routing` to `on`. This option is always `on` for the top-level group. Valid values are `on` or `off`. Default is `on` for subgroups. `enable_wal_decoder`,`boolean`,Enables/disables the decoding worker process. You can't enable the decoding worker process if `streaming_mode` is already enabled. Valid values are `on` or `off`. Default is `off`. `location`,`text`,Information about group location. This option is purely metadata for monitoring. Default is `''` (empty string). `monitor_http_port`,`integer`,Port the :ref:`Using the PGD Monitor` HTTP server listens on for member nodes. Default is the node's Postgres port plus 1005. `monitor_use_https`,`boolean`,"Whether :ref:`Using the PGD Monitor` serves its web UI, REST API, and Prometheus endpoint over HTTPS. Reuses each node's SSL certificate configuration unless overridden with :ref:`pg_upgrade ` . Default is `false`." `num_writers`,`integer`,Number of parallel writers for the subscription backing this node group. Valid values are `-1` or a positive integer. `-1` means the value specified by the GUC :ref:`pg_upgrade ` is used. `-1` is the default. `route_reader_max_lag`,`integer`,Maximum lag in bytes for a node to be considered a viable read-only node. Currently reserved for future use. `route_writer_max_lag`,`integer`,"Maximum lag in bytes of the new write candidate to be selected as write leader. If no candidate passes this, no writer is selected. Default is `-1`." `route_writer_wait_flush`,`boolean`,Whether to switch if PGD needs to wait for the flush. Currently reserved for future use. `server_max_prepared_statements`,`integer`,Maximum number of prepared statements Connection Manager caches on a pooled backend before forcing a `DEALLOCATE ALL` when the connection is released back to the pool under the `fast` `server_reset_mode`. Only consulted in `transaction` pool mode. Default is `200`. `server_pool_mode`,`text`,":ref:`Connection pooling` mode for Connection Manager. Valid values are `none` (no pooling, default), `session`, and `transaction`" `server_reset_mode`,`text`,"Cleanup behavior Connection Manager applies to a pooled backend connection in `transaction` pool mode before returning it to the pool. Valid values are `discard_all` (default, runs :ref:`pg_upgrade ` ) and `fast` (skips cleanup unless a transaction was left open or `server_max_prepared_statements` is exceeded). `session` pool mode always runs `DISCARD ALL` regardless of this setting. See :ref:`Connection pooling` ." `streaming_mode`,`text`,"Enables/disables streaming of large transactions. When set to `off`, streaming is disabled. When set to any other value, large transactions are decoded while they're still in progress, and the changes are sent to the downstream. If the value is set to `file`, then the incoming changes of streaming transactions are stored in a file and applied only after the transaction is committed on upstream. If the value is set to `writer`, then the incoming changes are directly sent to one of the writers, if available.
If :ref:`Parallel Apply` is disabled or no writer is free to handle streaming transactions, then the changes are written to a file and applied after the transaction is committed. If the value is set to `auto`, PGD tries to intelligently pick between `file` and `writer`, depending on the transaction property and available resources. You can't enable `streaming_mode` if the WAL decoder is already enabled. Default is `auto`.

For more details, see :ref:`Using with transaction streaming` ." `use_https`,`boolean`,"Whether the HTTP listener uses HTTPS. When enabled, the server certificate is used for TLS. Requires `ssl_cert_file` and `ssl_key_file` configured in `postgresql.conf` or via the command line. Changes take effect only after restarting the Connection Manager process. Default is `false`. See :ref:`Configuring Connection Manager` for more details." `failover_slot_scope`,`text`,"PGD 5.7 and later only. Sets the scope for Logical Slot Failover support. Valid values are `global` or `local`. Default is `local`. For more information, see :ref:`CDC Failover support` ." For configuration examples and a resolution workflow for the ``apply_error_*`` options, see :ref:`Handling replication apply errors ` . ``enable_fast_track_writer`` notes ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ When ``enable_fast_track_writer`` is off and the application uses Quorum Commit via the ``bdr.commit_scope`` configuration parameter, enable this option explicitly on the top-level group so the entire cluster has it enabled: .. code:: sql SELECT bdr.alter_node_group_option(topgroup, enable_fast_track_writer, true); Adding the fast track writer increases the number of replication slots required per node. Review the ``max_replication_slots`` calculation in :ref:`Postgres configuration parameters ` and, for PostgreSQL 18 and later, ``max_active_replication_origins`` . Use :ref:`bdr.get_min_required_replication_slots() ` to verify the values are high enough after enabling this option. Return value ^^^^^^^^^^^^ ``bdr.alter_node_group_option()`` returns ``VOID`` on success. An ``ERROR`` is raised if any of the provided parameters is invalid. Notes ^^^^^ You can examine the current state of node group options by way of the view :ref:`bdr.node_group_summary ` . This function passes a request to the group consensus mechanism to change the defaults. The changes made are replicated globally using the consensus mechanism. The function isn’t transactional. The request is processed in the background, so you can’t roll back the function call. Also, the changes might not be immediately visible to the current transaction. This function doesn’t hold any locks. bdr.alter_node_interface ------------------------ Changes the connection string (``DSN`` ) of a specified node. .. _synopsis-1: Synopsis ^^^^^^^^ .. code:: sql bdr.alter_node_interface(node_name text, interface_dsn text) .. _parameters-1: Parameters ^^^^^^^^^^ .. csv-table:: :header: Name,Description :widths: 10,30 :align: left :class: longtable `node_name`,Name of an existing node to alter. `interface_dsn`,New connection string for a node. .. _notes-1: Notes ^^^^^ Run this function and make the changes only on the local node. This means that you normally execute it on every node in the PGD group, including the node that’s being changed. This function is transactional. You can roll it back, and the changes are visible to the current transaction. The function holds lock on the local node. bdr.alter_node_option --------------------- Modifies per-node configuration options. .. _synopsis-2: Synopsis ^^^^^^^^ .. code:: sql bdr.alter_node_option(node_name text, config_key text, config_value text); .. _parameters-2: Parameters ^^^^^^^^^^ .. csv-table:: :header: Name,Description :widths: 10,30 :align: left :class: longtable `node_name`,Name of the node to change. `config_key`,Key of the option in the node to change. `config_value`,New value to set for the given key. The node options you can change using this function are: .. csv-table:: :header: Config Key,Description :widths: 10,30 :align: left :class: longtable `route_priority`,Relative routing priority of the node against other nodes in the same node group. Default is `'-1'`. `route_fence`,"Whether the node is fenced from routing. When true, the node can't receive connections from the Connection Manager. Replication is not impacted. Default is `'f'` (false)." `route_writes`,"Whether writes can be routed to this node, that is, whether the node can become write leader. Default is `'t'` (true) for data nodes and `'f'` (false) for other node types." `route_reads`,"Whether read-only connections can be routed to this node. Currently reserved for future use. Default is `'t'` (true) for data and subscriber-only nodes, `'f'` (false) for witness and standby nodes." `route_dsn`,"The dsn for the proxy to use to connect to this node. This option is optional. If not set, it defaults to the node's `node_dsn` value." `group_dsn`,"Preferred connection string for nodes in the same subgroup. When set, nodes within the same subgroup connect using this DSN instead of the node's `node_dsn`. Set to NULL to reset to the default. Stored in :ref:``bdr.node_config` columns<`bdr.node_config` columns>` as `node_group_dsn`." bdr.alter_subscription_enable ----------------------------- Enables either the specified subscription or all the subscriptions of the local PGD node. This is also known as resume subscription. No error is thrown if the subscription is already enabled. Returns the number of subscriptions affected by this operation. .. _synopsis-3: Synopsis ^^^^^^^^ .. code:: sql bdr.alter_subscription_enable( subscription_name name DEFAULT NULL, immediate boolean DEFAULT false ) .. _parameters-3: Parameters ^^^^^^^^^^ .. csv-table:: :header: Name,Description :widths: 10,30 :align: left :class: longtable `subscription_name`,"Name of the subscription to enable. If NULL (the default), all subscriptions on the local node are enabled." `immediate`,"Used to force the action immediately, starting all the workers associated with the enabled subscription. When this option is `true`, you can't run this function inside of the transaction block." .. _notes-2: Notes ^^^^^ This function isn’t replicated and affects only local node subscriptions (either a specific node or all nodes). This function is transactional. You can roll it back, and the current transaction can see any catalog changes. The subscription workers are started by a background process after the transaction has committed. bdr.alter_subscription_disable ------------------------------ Disables either the specified subscription or all the subscriptions of the local PGD node. Optionally, it can also immediately stop all the workers associated with the disabled subscriptions. This is also known as pause subscription. No error is thrown if the subscription is already disabled. Returns the number of subscriptions affected by this operation. .. _synopsis-4: Synopsis ^^^^^^^^ .. code:: sql bdr.alter_subscription_disable( subscription_name name DEFAULT NULL, immediate boolean DEFAULT false, fast boolean DEFAULT true ) .. _parameters-4: Parameters ^^^^^^^^^^ .. csv-table:: :header: Name,Description :widths: 10,30 :align: left :class: longtable `subscription_name`,"Name of the subscription to disable. If NULL (the default), all subscriptions on the local node are disabled." `immediate`,"Used to force the action immediately, stopping all the workers associated with the disabled subscription. When this option is `true`, you can't run this function inside of the transaction block." `fast`,"This argument influences the behavior of `immediate`. If set to `true` (the default), it stops all the workers associated with the disabled subscription without waiting for them to finish current work." .. _notes-3: Notes ^^^^^ This function isn’t replicated and affects only local node subscriptions (either a specific subscription or all subscriptions). This function is transactional. You can roll it back, and the current transaction can see any catalog changes. However, the timing of the subscription worker stopping depends on the value of ``immediate`` . If set to ``true`` , the workers receive the stop without waiting for the ``COMMIT`` . If the ``fast`` argument is set to ``true`` , the interruption of the workers doesn’t wait for current work to finish. bdr.create_node --------------- Creates a node. .. _synopsis-5: Synopsis ^^^^^^^^ .. code:: sql bdr.create_node(node_name text, local_dsn text, node_kind DEFAULT NULL) .. _parameters-5: Parameters ^^^^^^^^^^ .. csv-table:: :header: Name,Description :widths: 10,30 :align: left :class: longtable `node_name`,"Name of the new node. Only one node is allowed per database. Valid node names consist of lowercase letters, numbers, hyphens, and underscores." `local_dsn`,Connection string to the node. `node_kind`,"One of `data` (the default), `standby`, `subscriber-only`, or `witness`. If you don't set this parameter, or if you provide `NULL`, the default `data` node kind is used." .. _notes-4: Notes ^^^^^ This function creates a record for the local node with the associated public connection string. There can be only one local record, so once it’s created, the function reports an error if run again. This function is a transactional function. You can roll it back and the changes made by it are visible to the current transaction. The function holds lock on the newly created node until the end of the transaction. bdr.create_node_group --------------------- Creates a PGD node group. By default, the local node joins the group as the only member. You can add more nodes to the group with :ref:`bdr.join_node_group() <#bdrjoin_node_group>` . .. _synopsis-6: Synopsis ^^^^^^^^ .. code:: sql bdr.create_node_group(node_group_name text, parent_group_name text DEFAULT NULL, join_node_group boolean DEFAULT true, node_group_type text DEFAULT NULL) .. _parameters-6: Parameters ^^^^^^^^^^ .. csv-table:: :header: Name,Description :widths: 10,30 :align: left :class: longtable `node_group_name`,"Name of the new PGD group. As with the node name, valid group names consist of only lowercase letters, numbers, and underscores." `parent_group_name`,"If a node subgroup is being created, this must be the name of the parent group. Provide `NULL` (the default) when creating the main node group for the cluster." `join_node_group`,"Determines whether the node joins the group being created. The default value is `true`. Providing `false` when creating a subgroup means the local node won't join the new group, for example, when creating an independent remote group. In this case, you must specify `parent_group_name`." `node_group_type`,"The valid values are `NULL` or `subscriber-only`. `NULL` (the default) is for creating a normal, general-purpose node group. `subscriber-only` is for creating :ref:`Creating Subscriber-only groups and nodes` whose members receive changes only from the fully joined nodes in the cluster but that never send changes to other nodes." .. _notes-5: Notes ^^^^^ This function passes a request to the local consensus worker that’s running for the local node. The function isn’t transactional. The creation of the group is a background process, so once the function finishes, you can’t roll back the changes. Also, the changes might not be immediately visible to the current transaction. You can call ``bdr.wait_for_join_completion`` to wait until they are. The group creation doesn’t hold any locks. bdr.drop_node_group ------------------- Drops an empty PGD node group. If there are any joined nodes in the group, the function will fail. .. _synopsis-7: Synopsis ^^^^^^^^ .. code:: sql bdr.drop_node_group(node_group_name text) .. _parameters-7: Parameters ^^^^^^^^^^ .. csv-table:: :header: Name,Description :widths: 10,30 :align: left :class: longtable `node_group_name`,Name of the PGD group to drop. .. _notes-6: Notes ^^^^^ This function passes a request to the group consensus mechanism to drop the group. The function isn’t transactional. The dropping process happens in the background, and you can’t roll it back. bdr.join_node_group ------------------- Joins the local node to an already existing PGD group. .. _synopsis-8: Synopsis ^^^^^^^^ .. code:: sql bdr.join_node_group ( join_target_dsn text, node_group_name text DEFAULT NULL, wait_for_completion boolean DEFAULT true, synchronize_structure text DEFAULT all ) .. _parameters-8: Parameters ^^^^^^^^^^ .. csv-table:: :header: Name,Description :widths: 10,30 :align: left :class: longtable `join_target_dsn`,Specifies the connection string to an existing (source) node in the PGD group you want to add the local node to. `node_group_name`,"Optional name of the PGD group. Defaults to NULL, which tries to detect the group name from information present on the source node." `wait_for_completion`,Wait for the join process to complete before returning. Defaults to `true`. `synchronize_structure`,"Specifies whether to perform database structure (schema) synchronization during the join. `all`, the default setting, synchronizes the complete database structure. `none` does not synchronize any structure. However, data will still be synchronized, meaning the database structure must already be present on the joining node. Note that by design, neither schema nor data will ever be synchronized to witness nodes." If ``wait_for_completion`` is specified as ``false`` , the function call returns as soon as the joining procedure starts. You can see the progress of the join in the log files and the `bdr.event_summary `_ information view. You can call the function :ref:`bdr.wait_for_join_completion() ` after ``bdr.join_node_group()`` to wait for the join operation to complete. It can emit progress information if :ref:`bdr.wait_for_join_completion() ` is called with ``verbose_progress`` set to ``true`` . .. _notes-7: Notes ^^^^^ This function passes a request to the group consensus mechanism by way of the node that the ``join_target_dsn`` connection string points to. The changes made are replicated globally by the consensus mechanism. The function isn’t transactional and will emit an error if executed in a transaction. The joining process happens in the background and you can’t roll it back. The changes are visible only to the local session if ``wait_for_completion`` is set to ``true`` or by calling ``bdr.wait_for_join_completion`` later. A node can be part of only a single group, so you can call this function only once on each node. Node join doesn’t hold any locks in the PGD group. To reuse a node name while a parting process is still in progress, set ``concurrent = true`` when using ``bdr.part_node`` (requires Raft protocol version 6003 or above). This parameter allows the original name to be reused once the parting node reaches the ``PARTING`` state, at which point the node is automatically renamed to its UUID. It isn’t possible to join an additional data node to a node group where the existing nodes are configured as CAMO partners. To add the node, drop the CAMO commit scope first. bdr.part_node ------------- Removes (parts) the node from the PGD group and eventually removes the parted node’s metadata from all nodes in the cluster. - For the local node, it removes all the node metadata, including information about remote nodes. - For remote nodes, it removes only the metadata for that specific node. This operation doesn’t remove data from the node. You can call the function from any active node in the PGD group, including the node that you’re removing. It isn’t possible to part a data node if the group’s ``default_commit_scope`` or the local node’s ``bdr.commit_scope`` configuration parameter is set to a CAMO commit scope. To remove the node, drop the CAMO commit scope first. Executing parting from the node being removed runs the risk of incorrectly reporting, or never reporting, the status of the removal. This is because in the process of being removed, communications are cut off from the rest of the cluster. While the removal may succeed, there’s no way to inform the node that issued the command that it failed or succeeded on the other nodes. The function can’t be set to wait for completion either, for the same reason. Once a node has parted itself, it can’t part other nodes in the cluster as it’s no longer part of the cluster. We recommend avoiding using nodes to part themselves from the cluster. Instead, perform node parting operations from a node that can wait for completion and check the cluster status after the operation is complete. .. Note:: If you're parting the local node, you must set `wait_for_completion` to `false` . Otherwise, it reports an error. .. Warning:: This action is permanent. If you want to temporarily halt replication to a node, use `bdr.alter_subscription_disable()` . .. _synopsis-9: Synopsis ^^^^^^^^ .. code:: sql bdr.part_node ( node_name text, wait_for_completion boolean DEFAULT true, force boolean DEFAULT false, concurrent boolean DEFAULT false ) .. _parameters-9: Parameters ^^^^^^^^^^ .. csv-table:: :header: Name,Description :widths: 10,30 :align: left :class: longtable `node_name`,Name of an existing node to part. `wait_for_completion`,"If `true`, the function doesn't return until the node is fully parted from the cluster. Otherwise, the function starts the parting procedure and returns immediately without waiting. Always set to `false` when executing on the local node or when using `force`." `force`,Forces removal of the node on the local node. This sets the node state locally if consensus can't be reached or if the node-parting process is stuck. `concurrent`,"If `true`, allows reuse of parting node name as soon as node is in `PARTING` state or above, without waiting for the node to reach the `PARTED` state and eventually being dropped. Default is `false`. This parameter is available when the cluster is at Raft protocol version 6003 or above." .. Warning:: Using `force = true` can leave the PGD group in an inconsistent state. Use it only to recover from failures in which you can't remove the node any other way. .. _notes-8: Notes ^^^^^ This function passes a request to the group consensus mechanism to part the given node. The changes made are replicated globally by the consensus mechanism. The parting process happens in the background, and you can’t roll it back. The changes made by the parting process are visible only to the local transaction if ``wait_for_completion`` was set to ``true`` . With ``force`` set to ``true`` , on consensus failure, this function sets the state of the given node only on the local node. In such a case, the function is transactional (because the function changes the node state) and you can roll it back. If the function is called on a node that’s already in process of parting with ``force`` set to ``true`` , it also marks the given node as parted locally and exits. This is useful only when the consensus can’t be reached on the cluster (that is, the majority of the nodes are down) or if the parting process is stuck. But it’s important to take into account that when the parting node that was receiving writes, the parting process can take a long time without actually being stuck. The other nodes need to resynchronize any missing data from the given node. The other nodes need to wait till group slots of all nodes are caught up to all the transactions originating from the PARTED node. A forced parting completely skips this resynchronization and can leave the other nodes in an inconsistent state. The parting process doesn’t hold any locks. When ``concurrent = true`` , the target state for a parting node is set to ``PARTED_CONCURRENT`` . Upon reaching the ``PARTING`` state, the node is renamed to its UUID. The process continues until the node reaches the ``PARTED`` state and is dropped. Consequently, all tracking for the node must use its UUID once it moves past the ``PART_START`` state. We recommend setting ``wait_for_completion = false`` when using ``concurrent = true`` . This configuration allows the function to return with a ``Notice`` as soon as the original node reaches the ``PARTING`` state. At this precise moment, the node is renamed to its UUID, freeing the original name for immediate reassignment or reuse in the cluster. bdr.promote_node ---------------- Promotes a local logical standby node to a full member of the PGD group. .. _synopsis-10: Synopsis ^^^^^^^^ .. code:: sql bdr.promote_node(wait_for_completion boolean DEFAULT true) .. _notes-9: Notes ^^^^^ This function passes a request to the group consensus mechanism to change the defaults. The changes made are replicated globally by the consensus mechanism. The function isn’t transactional. The promotion process happens in the background, and you can’t roll it back. The changes are visible only to the local transaction if ``wait_for_completion`` was set to ``true`` or by calling ``bdr.wait_for_join_completion`` later. The promotion process holds lock against other promotions. This lock doesn’t block other ``bdr.promote_node`` calls but prevents the background process of promotion from moving forward on more than one node at a time. bdr.switch_node_group --------------------- Switches the local node from its current subgroup to another subgroup in the same existing PGD node group. .. _synopsis-11: Synopsis ^^^^^^^^ .. code:: sql bdr.switch_node_group ( node_group_name text, wait_for_completion boolean DEFAULT true ) .. _parameters-10: Parameters ^^^^^^^^^^ .. csv-table:: :header: Name,Description :widths: 10,30 :align: left :class: longtable `node_group_name`,Name of the PGD group or subgroup. `wait_for_completion`,Wait for the switch process to complete before returning. Defaults to `true`. If ``wait_for_completion`` is set to ``false`` , this is an asynchronous call that returns as soon as the switching procedure starts. You can see progress of the switch in logs and the ``bdr.event_summary`` information view or by calling the ``bdr.wait_for_join_completion()`` function after ``bdr.switch_node_group()`` returns. .. _notes-10: Notes ^^^^^ This function passes a request to the group consensus mechanism. The changes made are replicated globally by the consensus mechanism. The function isn’t transactional. The switching process happens in the background and you can’t roll it back. The changes are visible only to the local transaction if ``wait_for_completion`` was set to ``true`` or by calling ``bdr.wait_for_join_completion`` later. The local node changes membership from its current subgroup to another subgroup in the same PGD node group without needing to part the cluster. The node’s kind must match that of existing nodes in the target subgroup. Node switching doesn’t hold any locks in the PGD group. Restrictions: currently, the function allows switching only between a subgroup and its PGD node group. To effect a move between subgroups you need to make two separate calls: 1) switch from subgroup to node group and, 2) switch from node group to other subgroup. bdr.sync_node_cancel -------------------- This function cancels a sync request for the specified origin and source nodes. .. _synopsis-12: Synopsis ^^^^^^^^ .. code:: sql bdr.sync_node_cancel(origin text, source text) .. _parameters-11: Parameters ^^^^^^^^^^ .. csv-table:: :header: Name,Description :widths: 10,30 :align: left :class: longtable `origin`,Name of the origin node. `source`,Name of the source node. .. _notes-11: Notes ^^^^^ This function cancels all sync node requests for all targets that have the given origin and source. You can invoke it only from a write lead. bdr.wait_for_join_completion ---------------------------- This function waits for the join procedure of a local node to finish. .. _synopsis-13: Synopsis ^^^^^^^^ .. code:: sql bdr.wait_for_join_completion(verbose_progress boolean DEFAULT false) .. _parameters-12: Parameters ^^^^^^^^^^ .. csv-table:: :header: Name,Description :widths: 10,30 :align: left :class: longtable `verbose_progress`,Optionally prints information about individual steps taken during the join procedure. .. _notes-12: Notes ^^^^^ This function waits until the checks state of the local node reaches the target state, which was set by ``bdr.create_node_group`` , ``bdr.join_node_group`` , or ``bdr.promote_node`` .