Merge pull request #2682 from EnterpriseDB/release/2202-05-17a

Release: 2202-05-17a

product_docs/docs/bdr/4/appusage.mdx

@@ -174,7 +174,7 @@ a cluster, you can't add a node with a minor version if the cluster
 uses a newer protocol version. This returns an error.
 
 Both of these features might be affected by specific restrictions. 
-See [Release notes](release-notes) for any known incompatibilities.
+See [Release notes](release_notes) for any known incompatibilities.
 
 ## Replicating between nodes with differences
 
@@ -323,9 +323,9 @@ its different modes.
 You can test BDR applications using the following programs,
 in addition to other techniques.
 
--   [TPAexec]
--   [pgbench with CAMO/Failover options]
--   [isolationtester with multi-node access]
+-   [TPAexec](#TPAexec)
+-   [pgbench with CAMO/Failover options](#pgbench-with-camofailover-options)
+-   [isolationtester with multi-node access](#isolationtester-with-multi-node-access)
 
 ### TPAexec
 

product_docs/docs/bdr/4/camo.mdx

@@ -110,7 +110,7 @@ Valid values for `bdr.enable_camo` that enable CAMO are:
 * `remote_commit_async`
 * `remote_commit_flush` or `on`
 
-See the [Comparison](durability#Comparison) of synchronous replication
+See the [Comparison](durability/#comparison) of synchronous replication
 modes for details about how each mode behaves.
 Setting `bdr.enable_camo = off` disables this feature, which is the default.
 
@@ -580,4 +580,4 @@ outages.
 ## CAMO versus group commit
 
 CAMO doesn't currently work with
-[group commit](group_commit).
+[group commit](group-commit).

product_docs/docs/bdr/4/catalogs.mdx

@@ -129,7 +129,7 @@ managing global consensus.
 As for the `bdr.global_consensus_response_journal` catalog, the
 payload is stored in a binary encoded format, which can be decoded
 with the `bdr.decode_message_payload()` function. See the
-[`bdr.global_consensus_journal_details`] view for more details.
+[`bdr.global_consensus_journal_details`](#bdrglobal-consensus-journal-details) view for more details.
 
 #### `bdr.global_consensus_journal` columns
 
@@ -176,7 +176,7 @@ that were received while managing global consensus.
 As for the `bdr.global_consensus_journal` catalog, the payload is
 stored in a binary-encoded format, which can be decoded with the
 `bdr.decode_message_payload()` function. See the
-[`bdr.global_consensus_journal_details`] view for more details.
+[`bdr.global_consensus_journal_details`](#bdrglobal-consensus-journal-details) view for more details.
 
 #### `bdr.global_consensus_response_journal` columns
 
@@ -214,11 +214,11 @@ Don't modify the contents of this table. It is an important BDR catalog.
 
 ### `bdr.global_locks`
 
-A view containing active global locks on this node. The `bdr.global_locks` view
+A view containing active global locks on this node. The [`bdr.global_locks`](#bdrglobal-locks) view
 exposes BDR's shared-memory lock state tracking, giving administrators greater
 insight into BDR's global locking activity and progress.
 
-See [Monitoring global locks](monitoring#Monitoring-global-locks)
+See [Monitoring global locks](/pgd/latest/monitoring#monitoring-global-locks)
 for more information about global locking.
 
 #### `bdr.global_locks` columns
@@ -310,7 +310,7 @@ This table identifies the local node in the current database of the current Post
 
 ### `bdr.local_node_summary`
 
-A view containing the same information as [`bdr.node_summary`] but only for the
+A view containing the same information as [`bdr.node_summary`](#bdrnode-summary) but only for the
 local node.
 
 ### `bdr.local_sync_status`
@@ -481,7 +481,7 @@ Every node in the cluster regularly broadcasts its progress every
 is 60000 ms, i.e., 1 minute). Expect N \* (N-1) rows in this relation.
 
 You might be more interested in the `bdr.node_slots` view for monitoring
-purposes. See also [Monitoring](monitoring).
+purposes. See also [Monitoring](/pgd/latest/monitoring).
 
 #### `bdr.node_peer_progress` columns
 
@@ -543,7 +543,7 @@ given node.
 This view contains information about replication slots used in the current
 database by BDR.
 
-See [Monitoring outgoing replication](monitoring#monitoring-outgoing-replication)
+See [Monitoring outgoing replication](/pgd/latest/monitoring#monitoring-outgoing-replication)
 for guidance on the use and interpretation of this view's fields.
 
 #### `bdr.node_slots` columns
@@ -559,7 +559,7 @@ for guidance on the use and interpretation of this view's fields.
 | target_id           | oid         | The OID of the target node                                                                                                              |
 | local_slot_name     | name        | Name of the replication slot according to BDR                                                                                           |
 | slot_name           | name        | Name of the slot according to Postgres (same as above)                                                                                 |
-| is_group_slot       | boolean     | True if the slot is the node-group crash recovery slot for this node (see ["Group Replication Slot"]\(nodes.md#Group Replication Slot)) |
+| is_group_slot       | boolean     | True if the slot is the node-group crash recovery slot for this node (see ["Group Replication Slot"]\(nodes#Group Replication Slot)) |
 | is_decoder_slot     | boolean     | Is this slot used by Decoding Worker                                                                                                    |
 | plugin              | name        | Logical decoding plugin using this slot (should be pglogical_output or bdr)                                                             |
 | slot_type           | text        | Type of the slot (should be logical)                                                                                                    |

product_docs/docs/bdr/4/column-level-conflicts.mdx

@@ -189,7 +189,7 @@ SELECT bdr.column_timestamps_enable('test_table'::regclass, 'cts', true);
 You can disable it using `bdr.column_timestamps_disable`.
 
 Commit timestamps currently have restrictions that are
-explained in [Limitations](#limitations).
+explained in [Notes](#notes).
 
 ## Inspecting column timestamps
 

product_docs/docs/bdr/4/configuration.mdx

@@ -82,7 +82,7 @@ Unless noted otherwise, you can set the values at any time.
 
 ### Global sequence parameters
 
--   `bdr.default_sequence_kind` — Sets the default [sequence kind](sequences.md).
+-   `bdr.default_sequence_kind` — Sets the default [sequence kind](sequences).
     The default value is `distributed`, which means `snowflakeid` is used
     for `int8` sequences (i.e., `bigserial`) and `galloc` sequence for `int4`
     (i.e., `serial`) and `int2` sequences.
@@ -138,7 +138,7 @@ Unless noted otherwise, you can set the values at any time.
     across all nodes might cause replicated DDL to interrupt replication until
     the administrator intervenes.
 
-    See [Role manipulation statements](ddl#Role_manipulation_statements)
+    See [Role manipulation statements](ddl#role-manipulation-statements)
     for details.
 
 -   `bdr.ddl_locking` — Configures the operation mode of global locking for DDL.
@@ -366,7 +366,7 @@ time of each type of worker. This tracking table isn't persistent. It is
 cleared by PostgreSQL restarts, including soft restarts during crash recovery
 after an unclean backend exit.
 
-You can use the view [`bdr.worker_tasks`](monitoring#bdr.worker_tasks) to inspect this state so the administrator can see any backoff
+You can use the view [`bdr.worker_tasks`](catalogs#bdrworker_tasks) to inspect this state so the administrator can see any backoff
 rate limiting currently in effect.
 
 For rate limiting purposes, workers are classified by task. This key consists

product_docs/docs/bdr/4/conflicts.mdx

@@ -928,7 +928,7 @@ The recognized methods for conflict detection are:
 
 For more information about the difference between `column_commit_timestamp`
 and `column_modify_timestamp` conflict detection methods, see
-[Current vs Commit Timestamp](column-level-conflicts#current-vs-commit-timestamp])
+[Current vs Commit Timestamp](column-level-conflicts#current-versus-commit-timestamp)
 section in the CLCD chapter.
 
 This function uses the same replication mechanism as `DDL` statements. This

product_docs/docs/bdr/4/ddl.mdx

@@ -24,7 +24,7 @@ the DDL change to all nodes and ensure that they are consistent.
 
 In the default replication set, DDL is replicated to all nodes by default.
 To replicate DDL, a DDL replication filter has to be added to the
-replication set. See [DDL Replication Filtering].
+replication set. See [DDL replication filtering](#ddr-replication-filtering).
 
 BDR is significantly different to standalone PostgreSQL when it
 comes to DDL replication, and treating it as the same is the most
@@ -179,7 +179,7 @@ down node must first be removed from the configuration.
 If a DDL statement is not replicated, no global locks will be acquired.
 
 Locking behavior is specified by the `bdr.ddl_locking` parameter, as
-explained in [Executing DDL on BDR systems](#Executing-DDL-on-BDR-systems):
+explained in [Executing DDL on BDR systems](#executing-ddl-on-bdr-systems):
 
 -   `ddl_locking = on` takes Global DDL Lock and, if needed, takes Relation DML Lock.
 -   `ddl_locking = dml` skips Global DDL Lock and, if needed, takes Relation DML Lock.
@@ -207,15 +207,15 @@ DDL replication is not active on Logical Standby nodes until they are promoted.
 Note that some BDR management functions act like DDL, meaning that they will
 attempt to take global locks and their actions will be replicated, if DDL
 replication is active. The full list of replicated functions is listed in
-[BDR Functions that behave like DDL].
+[BDR functions that behave like DDL](#bdr-functions-that-behave-like-ddl).
 
 DDL executed on temporary tables never need global locks.
 
 ALTER or DROP of an object crrated in current transactioon does not required
 global DML lock.
 
 Monitoring of global DDL locks and global DML locks is shown in the
-[Monitoring](monitoring) chapter.
+[Monitoring](/pgd/latest/monitoring) chapter.
 
 ## Minimizing the Impact of DDL
 
@@ -324,7 +324,7 @@ BDR prevents some DDL statements from running when it is active on a
 database. This protects the consistency of the system by disallowing
 statements that cannot be replicated correctly, or for which replication is
 not yet supported. Statements that are supported with some restrictions
-are covered in [DDL Statements With Restrictions]; while commands that are
+are covered in [DDL Statements With Restrictions](#ddl-statements-with-restrictions); while commands that are
 entirely disallowed in BDR are covered in prohibited DDL statements.
 
 If a statement is not permitted under BDR, it is often possible to find

product_docs/docs/bdr/4/durability.mdx

@@ -18,7 +18,7 @@ can all be implemented individually:
     eventually be applied on all nodes without further conflicts, or get
     an abort directly informing the client of an error.
 
-BDR provides a [Group Commit](group_commit.md) feature to guarante
+BDR provides a [Group Commit](group-commit) feature to guarantee
 durability and visibility by providing a variant of synchronous
 replication.  This is very similar to Postgres' `synchronous_commit`
 feature for physical standbys, but providing a lot more flexibility
@@ -45,8 +45,8 @@ Postgres itself provides [Physical Streaming Replication](https://www.postgresql
 (PSR), which is uni-directional, but offers a [synchronous variant](https://www.postgresql.org/docs/current/warm-standby.html#SYNCHRONOUS-REPLICATION).
 For backwards compatibility, BDR still supports configuring synchronous
 replication via `synchronous_commit` and `synchronous_standby_names`, see
-[Legacy Synchronous Replication](durability.md#legacy-synchronous-replication),
-but the use of [Group Commit](group_commit.md) is recommended instead
+[Legacy Synchronous Replication](durability#legacy-synchronous-replication-using-bdr),
+but the use of [Group Commit](group-commit) is recommended instead
 in all cases.
 
 This chapter covers the various forms of synchronous or eager
@@ -85,7 +85,7 @@ Synchronous Replication with BDR, it refers to the
 `synchronous_commit` setting. For CAMO, it refers to the
 `bdr.enable_camo` setting. Lastly, for Group Commit, it refers to the
 confirmation requirements of the
-[commit scope configuration](group_commit#configuration).
+[commit scope configuration](group-commit#configuration).
 
 | Variant      | Mode                          | Received | Visible  | Durable  |
 |--------------|-------------------------------|----------|----------|----------|
@@ -214,7 +214,7 @@ required synchronization level and prevents loss of data.
 
 !!! Note
     This approach is not recommended.  Please consider using
-    [Group Commit](group_commit.md) instead.
+    [Group Commit](group-commit) instead.
 
 ### Usage
 

product_docs/docs/bdr/4/eager.mdx

@@ -5,7 +5,7 @@ title: Eager Replication
 To prevent conflicts after a commit, set the `bdr.commit_scope`
 parameter to `global`.  The default setting of `local` disables eager
 replication, so BDR will apply changes and resolve potential conflicts
-post-commit, as described in the [Conflicts chapter](conflicts.md).
+post-commit, as described in the [Conflicts chapter](conflicts).
 
 In this mode, BDR uses two-phase commit (2PC) internally to detect and
 resolve conflicts prior to the local commit.  It turns a normal
@@ -33,7 +33,7 @@ Eager All-Node Replication uses prepared transactions internally;
 therefore all replica nodes need to have a `max_prepared_transactions`
 configured high enough to be able to handle all incoming transactions
 (possibly in addition to local two-phase commit and CAMO transactions;
-see [Configuration: Max Prepared Transactions](configuration.md#max-prepared-transactions)).
+see [Configuration: Max Prepared Transactions](configuration#max-prepared-transactions)).
 We recommend to configure it the same on all nodes, and high enough to
 cover the maximum number of concurrent transactions across the cluster
 for which CAMO or Eager All-Node Replication is used.  Other than
@@ -93,8 +93,7 @@ Eager transactions).
 
 Other than this difference in configuration and invocation of that
 function, the client needs to adhere to the protocol
-described for [CAMO](camo.md).  See the [reference client
-implementations](camo_clients.md).
+described for [CAMO](camo).  See the [reference client implementations](camo_clients).
 
 ### Limitations
 

product_docs/docs/bdr/4/functions.mdx

@@ -689,7 +689,7 @@ bdr.monitor_group_versions()
 #### Notes
 
 This function returns a record with fields `status` and `message`,
-as explained in [Monitoring].
+as explained in [Monitoring](#monitoring).
 
 This function calls `bdr.run_on_all_nodes()`.
 
@@ -708,7 +708,7 @@ bdr.monitor_group_raft()
 #### Notes
 
 This function returns a record with fields `status` and `message`,
-as explained in [Monitoring].
+as explained in [Monitoring](#monitoring).
 
 This function calls `bdr.run_on_all_nodes()`.
 
@@ -728,11 +728,11 @@ bdr.monitor_local_replslots()
 #### Notes
 
 This function returns a record with fields `status` and `message`,
-as explained in [Monitoring Replication Slots](monitoring.md#monitoring-replication-slots).
+as explained in [Monitoring Replication Slots](/pgd/latest/monitoring/#monitoring-replication-slots).
 
 ### bdr.wal_sender_stats
 
-If the [Decoding Worker](nodes.md#decoding-worker) is enabled, this
+If the [Decoding Worker](nodes#decoding-worker) is enabled, this
 function shows information about the decoder slot and current LCR
 (`Logical Change Record`) segment file being read by each WAL sender.
 
@@ -755,7 +755,7 @@ bdr.wal_sender_stats() → setof record (pid integer, is_using_lcr boolean,
 
 ### bdr.get_decoding_worker_stat
 
-If the [Decoding Worker](nodes.md#decoding-worker) is enabled, this function
+If the [Decoding Worker](nodes#decoding-worker) is enabled, this function
 shows information about the state of the Decoding Worker associated with the
 current database. This also provides more granular information about Decoding
 Worker progress than is available via `pg_replication_slots`.
@@ -778,11 +778,11 @@ bdr.get_decoding_worker_stat()  → setof record (pid integer, decoded_upto_l
 
 #### Notes
 
-For further details see [Monitoring WAL senders using LCR](monitoring.md#monitoring-wal-senders-using-lcr).
+For further details see [Monitoring WAL senders using LCR](/pgd/latest/monitoring/#monitoring-wal-senders-using-lcr).
 
 ### bdr.lag_control
 
-If [Lag Control](lag-control.mdx#configuration) is enabled, this function
+If [Lag Control](lag-control#configuration) is enabled, this function
 shows information about the commit delay and number of nodes conforming
 to their configured lag measure for the local node and current database.
 
@@ -899,7 +899,7 @@ consensus mechanism is working.
 Internal implementation of sequence increments.
 
 This function will be used instead of standard `nextval` in queries which
-interact with [BDR Global Sequences].
+interact with [BDR Global Sequences](#bdr-global-sequences).
 
 #### Notes
 

product_docs/docs/bdr/4/group-commit.mdx

@@ -94,7 +94,7 @@ SELECT bdr.add_commit_scope(
 ### Confirmation Levels
 
 BDR nodes can send confirmations for a transaction at different points
-in time, similar to [Commit At Most Once](camo.md).  In increasing
+in time, similar to [Commit At Most Once](camo).  In increasing
 levels of protection, from the perspective of the confirming node,
 these are:
 

product_docs/docs/bdr/4/index.mdx

@@ -51,7 +51,7 @@ Detailed overview about how BDR works is described in the
 
 BDR is compatible with PostgresSQL, EDB Postgres Extended and EDB Postgres
 Advanced flavors of PostgresSQL database servers and can be deployed as a
-standard PG extension. See [Comptibility Matrix](pgd/latest/compatibility_matrix/)
+standard PG extension. See [Comptibility Matrix](/pgd/latest/compatibility_matrix/)
 for details of supported version combinations.
 
 It is important to note that some key BDR features depend on certain core

product_docs/docs/bdr/4/lag-control.mdx

@@ -71,7 +71,7 @@ of milliseconds with a fractional part including a sub-millisecond
 setting if appropriate.
 
 By default, `bdr.lag_control_min_conforming_nodes` is set to one (1).
-For a complete list, see [Lag Control](configuration.md)
+For a complete list, see [Lag Control](configuration)
 
 ## Overview