Docs/pgd/fix prerelease (#6873)

djw-m · web-flow · commit aebafa4cfc42 · 2025-06-10T09:34:02.000+01:00
* Fix replication page

Signed-off-by: Dj Walker-Morgan &lt;dj.walker-morgan@enterprisedb.com&gt;

* Some fixes for link checking (local 0 bad paths)

Signed-off-by: Dj Walker-Morgan &lt;dj.walker-morgan@enterprisedb.com&gt;

---------

Signed-off-by: Dj Walker-Morgan &lt;dj.walker-morgan@enterprisedb.com&gt;
diff --git a/product_docs/docs/pgd/6/concepts/replication.mdx b/product_docs/docs/pgd/6/concepts/replication.mdx
@@ -30,9 +30,8 @@ Asynchronous replication is the default mode of replication, but not the only on
 
 In PGD, the following types of changes are replicated:
 
-    - **Data changes**: Inserts, updates, and deletes to tables are replicated to all nodes in the cluster. This is called DML (Data Manipulation Language) replication.
-    - **Schema changes**: Changes to the structure of the database, such as creating or dropping tables, are also replicated to all nodes in the cluster. This is called DDL (Data Definition Language) replication. But not all DDL changes are replicated. For example, adding a column to a table is replicated, but dropping a column is not.
-    - **Configuration changes**: Changes to the configuration of the database, such as changing the replication settings, are also replicated to all nodes in the cluster.  
+- **Data changes**: Inserts, updates, and deletes to tables are replicated to all nodes in the cluster. This is called DML (Data Manipulation Language) replication.
+- **Schema changes**: Changes to the structure of the database, such as creating or dropping tables, are also replicated to all nodes in the cluster. This is called DDL (Data Definition Language) replication. But not all DDL changes are replicated. For example, adding a column to a table is replicated, but dropping a column is not.
+- **Configuration changes**: Changes to the configuration of the database, such as changing the replication settings, are also replicated to all nodes in the cluster.  
 
 Currently, PGD only replicates one Postgres database per cluster. This means that if you have multiple databases in your Postgres instance, only the database that is configured for replication will be replicated to the other nodes in the cluster. This is the same for both PGD Essential and PGD Expanded.
-
diff --git a/product_docs/docs/pgd/6/known_issues.mdx b/product_docs/docs/pgd/6/known_issues.mdx
@@ -56,7 +56,7 @@ To modify a commit scope safely, use [`bdr.alter_commit_scope`](/pgd/latest/refe
 
 -   The EBD Postgres Advanced Server 17 data type [`BFILE`](/epas/latest/reference/sql_reference/02_data_types/03a_bfiles/) is not currently supported. This is due to `BFILE` being a file reference that is stored in the database, and the file itself is stored outside the database and not replicated.
 
--   EDB Postgres Advanced Server's native autopartioning is not supported in PGD. See [Restrictions on EDB Postgres Advanced Server-native automatic partitioning](reference/tables-views-functions/autopartition/#restrictions-on-edb-postgres-advanced-server-native-automatic-partitioning) for more information.
+-   EDB Postgres Advanced Server's native autopartioning is not supported in PGD. See [Restrictions on EDB Postgres Advanced Server-native automatic partitioning](/pgd/latest/reference/autopartition/#restrictions-on-edb-postgres-advanced-server-native-automatic-partitioning) for more information.
 
 ## Limitations
 
diff --git a/product_docs/docs/pgd/6/reference/commit-scopes/index.mdx b/product_docs/docs/pgd/6/reference/commit-scopes/index.mdx
@@ -37,47 +37,36 @@ PGD Essential offers a limited set of commit scopes that are pre-defined and can
 
 ## Introducing
 
-* [Overview](overview) introduces the concepts and some of the essential 
-terminology that's used when discussing synchronous commits.
+* [Overview](/pgd/latest/reference/commit-scopes/overview) introduces the concepts and some of the essential terminology that's used when discussing synchronous commits.
 
-* [Durability terminology](durabilityterminology) lists terms used around PGD's 
-durability options, including how to refer to nodes in replication.
+* [Durability terminology](/pgd/latest/reference/commit-scopes/durabilityterminology) lists terms used around PGD's durability options, including how to refer to nodes in replication.
 
-* [Commit scopes](commit-scopes) is a more in-depth look at the structure
-of commit scopes and how to define them for your needs.
+* [Commit scopes](/pgd/latest/reference/commit-scopes/commit-scopes) is a more in-depth look at the structure of commit scopes and how to define them for your needs.
 
-* [Predefined commit scopes](predefined-commit-scopes) lists the pre-defined commit scopes that are available in PGD Essential.
+* [Predefined commit scopes](/pgd/latest/reference/commit-scopes/predefined-commit-scopes) lists the pre-defined commit scopes that are available in PGD Essential.
 
-* [Origin groups](origin_groups) introduces the notion of an origin group, and how to leverage these when defining commit scopes rules.
+* [Origin groups](/pgd/latest/reference/commit-scopes/origin_groups) introduces the notion of an origin group, and how to leverage these when defining commit scopes rules.
 
-* [Commit scope rules](commit-scope-rules) looks at the syntax of and how to formulate
-a commit scope rule.
+* [Commit scope rules](/pgd/latest/reference/commit-scopes/commit-scope-rules) looks at the syntax of and how to formulate a commit scope rule.
 
-* [Comparing durability options](comparing) compares how commit scope options behave with regard to durability.
+* [Comparing durability options](/pgd/latest/reference/commit-scopes/comparing) compares how commit scope options behave with regard to durability.
 
-* [Degrading commit scope rules](degrading) shows how to set up a commit scope rule that can gracefully degrade to a lower setting in case of timeouts with a stricter setting.
+* [Degrading commit scope rules](/pgd/latest/reference/commit-scopes/degrading) shows how to set up a commit scope rule that can gracefully degrade to a lower setting in case of timeouts with a stricter setting.
 
 ## Commit scope kinds
 
-* [Synchronous Commit](synchronous_commit) is a commit scope mechanism that works
-in a similar fashion to legacy synchronous replication, but from within the commit scope framework.
+* [Synchronous Commit](/pgd/latest/reference/commit-scopes/synchronous_commit) is a commit scope mechanism that works in a similar fashion to legacy synchronous replication, but from within the commit scope framework.
 
-* [Group Commit](group-commit) focuses on the Group Commit option, where you can
-define a transaction as done when a group of nodes agrees it's done.
+* [Group Commit](/pgd/latest/reference/commit-scopes/group-commit) focuses on the Group Commit option, where you can define a transaction as done when a group of nodes agrees it's done.
 
-* [CAMO](camo) focuses on the Commit At Most Once option, in which applications
-take responsibility for verifying that a transaction has been committed before
-retrying. This ensures that their commits only happen at most once.
+* [CAMO](/pgd/latest/reference/commit-scopes/camo) focuses on the Commit At Most Once option, in which applications take responsibility for verifying that a transaction has been committed before retrying. This ensures that their commits only happen at most once.
 
-* [Lag Control](lag-control) looks at the commit scope mechanism which
-dynamically throttle nodes according to the slowest node and regulates how far
-out of sync nodes may go when a database node goes out of service.
+* [Lag Control](/pgd/latest/reference/commit-scopes/lag-control) looks at the commit scope mechanism which dynamically throttle nodes according to the slowest node and regulates how far out of sync nodes may go when a database node goes out of service.
 
 ## Working with commit scopes
 
-* [Administering](administering) addresses how to manage a PGD cluster with Group Commit
-in use.
+* [Administering](/pgd/latest/reference/commit-scopes/administering) addresses how to manage a PGD cluster with Group Commit in use.
 
-* [Legacy synchronous replication](legacy-sync) shows how you can still access traditional Postgres synchronous operations under PGD.
+* [Legacy synchronous replication](/pgd/latest/reference/commit-scopes/legacy-sync) shows how you can still access traditional Postgres synchronous operations under PGD.
 
-* [Internal timing of operations](timing) compares legacy replication with PGD's async and synchronous operations, especially the difference in the order by which transactions are flushed to disk or made visible.
+* [Internal timing of operations](/pgd/latest/reference/commit-scopes/timing) compares legacy replication with PGD's async and synchronous operations, especially the difference in the order by which transactions are flushed to disk or made visible.
diff --git a/product_docs/docs/pgd/6/reference/conflict-management/conflicts/00_conflicts_overview.mdx b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/00_conflicts_overview.mdx
@@ -45,7 +45,7 @@ This avoidance happens naturally in many applications. For example, many consume
 
 You might make a change just before a node goes down, so the change seems to be lost. You might then make the same change again, leading to two updates on different nodes. When the down node comes back up, it tries to send the older change to other nodes. It's rejected because the last update of the data is kept.
 
-For `INSERT`/`INSERT` conflicts, use [global sequences](../../sequences/#pgd-global-sequences) to prevent this type of conflict.
+For `INSERT`/`INSERT` conflicts, use [global sequences](/pgd/latest/reference/sequences#pgd-global-sequences) to prevent this type of conflict.
 
 For applications that assign relationships between objects, such as a room-booking application, applying `update_if_newer` might not give an acceptable business outcome. That is, it isn't useful to confirm to two people separately that they have booked the same room. The simplest resolution is to use Eager Replication to ensure that only one booking succeeds. More complex ways might be possible depending on the application. For example, you can assign 100 seats to each node and allow those to be booked by a writer on that node. But if none are available locally, use a distributed locking scheme or Eager Replication after most seats are reserved.
 
diff --git a/product_docs/docs/pgd/6/reference/conflict-management/conflicts/02_types_of_conflict.mdx b/product_docs/docs/pgd/6/reference/conflict-management/conflicts/02_types_of_conflict.mdx
@@ -31,7 +31,7 @@ This conflict generates the `insert_exists` conflict type, which is by default r
 
 To resolve this conflict type, you can also use column-level conflict resolution and user-defined conflict triggers.
 
-You can effectively eliminate this type of conflict by using [global sequences](../../sequences/#pgd-global-sequences).
+You can effectively eliminate this type of conflict by using [global sequences](/pgd/latest/reference/sequences#pgd-global-sequences).
 
 ### INSERT operations that violate UNIQUE or EXCLUDE constraints
 
diff --git a/product_docs/docs/pgd/6/reference/nodes/index.mdx b/product_docs/docs/pgd/6/reference/nodes/index.mdx
@@ -14,12 +14,12 @@ redirects:
 
 A PGD cluster can contain several different types of node, each with its own role. This section describes the different types of node that can be configured in a PGD cluster.
 
-* [Overview](overview) is an overview the kinds of node that can exist in PGD clusters and their associated roles.
+* [Overview](/pgd/latest/reference/nodes/overview) is an overview the kinds of node that can exist in PGD clusters and their associated roles.
 
-* [Witness nodes](witness_nodes) looks at the witness node, a special class of PGD node, dedicated to establishing consensus in a group.
+* [Witness nodes](/pgd/latest/reference/nodes/witness_nodes) looks at the witness node, a special class of PGD node, dedicated to establishing consensus in a group.
 
-* [Logical standby nodes](logical_standby_nodes) shows how to efficiently keep a node on standby synchronized and ready to step in as a primary in the case of failure.
+* [Logical standby nodes](/pgd/latest/reference/nodes/logical_standby_nodes) shows how to efficiently keep a node on standby synchronized and ready to step in as a primary in the case of failure.
 
-* [Subscriber-only nodes and groups](subscriber_only) looks at how subscriber-only nodes work with subscriber-only groups, how they boost read scalability and the different options for configuring them.
+* [Subscriber-only nodes and groups](/pgd/latest/reference/nodes/subscriber_only) looks at how subscriber-only nodes work with subscriber-only groups, how they boost read scalability and the different options for configuring them.
 
 
diff --git a/product_docs/docs/pgd/6/reference/sequences.mdx b/product_docs/docs/pgd/6/reference/sequences.mdx
@@ -21,7 +21,7 @@ means of discarded `INSERT` actions in multi-master replication.
 
 !!! Note Permissions required
 This means that any user who wants to use sequences
-must have at least the [bdr_application](security/pgd-predefined-roles/#bdr_application) 
+must have at least the [bdr_application](/pgd/latest/reference/security/pgd-predefined-roles#bdr_application) 
 role assigned to them.
 !!!
 
@@ -92,7 +92,7 @@ The `currval()` and `lastval()` functions work correctly for all types of global
 
 In PGD 6.0 and later, the act of joining a node to a PGD group or creating a new grou also triggers a conversion of any local sequences into global sequences. Set [`bdr.default_sequence_kind`](/pgd/latest/reference/tables-views-functions/pgd-settings/#bdrdefault_sequence_kind) to `distributed`. This setting then selects the best kind of sequence to convert the local sequences into. If `bdr.default_sequence_kind` is set to `local`, the sequences are left as local sequences. Conversions to `galloc` are performed in a way that ensures that the sequence doesn't conflict with any other sequences in the group.
 
-If you decide to start with local sequences and later switch to galloc sequences, you can do so by setting `bdr.default_sequence_kind` to `galloc` and then running the `bdr.alter_sequence_set_kind()` function on each sequence you want to convert. Be aware, though, that you need to manually set the starting values of the sequences to ensure that they don't conflict with any existing values in the table. See [Converting a local sequence to a galloc sequence](#converting-a-local-sequence-to-a-galloc-sequence) for more information about this in general and specifically [How to set a new start value for a sequence](#2-set-a-new-start-value-for-the-sequence).
+If you decide to start with local sequences and later switch to galloc sequences, you can do so by setting `bdr.default_sequence_kind` to `galloc` and then running the `bdr.alter_sequence_set_kind()` function on each sequence you want to convert. Be aware, though, that you need to manually set the starting values of the sequences to ensure that they don't conflict with any existing values in the table. See [Converting a local sequence to a galloc sequence](/pgd/latest/reference/sequences#converting-a-local-sequence-to-a-galloc-sequence) for more information about this in general and specifically [How to set a new start value for a sequence](/pgd/latest/reference/sequences#2-set-a-new-start-value-for-the-sequence).
 
 ### SnowflakeId sequences
 
@@ -309,7 +309,7 @@ When the sequence kind is altered to `galloc`, it's rewritten and restarts from
 the defined start value of the local sequence. If this happens on an existing
 sequence in a production database, you need to query the current value and
 then set the start value appropriately. To help with this use case, PGD
-lets you pass a starting value with the function [`bdr.alter_sequence_set_kind()`](tables-views-functions/sequences/#bdralter_sequence_set_kind).
+lets you pass a starting value with the function [`bdr.alter_sequence_set_kind()`](/pgd/latest/reference/tables-views-functions/sequences#bdralter_sequence_set_kind).
 If you're already using offset and you have writes from multiple nodes, you
 need to check what's the greatest used value and restart the sequence to at least
 the next value:
@@ -347,7 +347,7 @@ SELECT * FROM bdr.sequence_alloc
 
 
 To see the ranges currently assigned to a given sequence on each node, execute the function
-[`bdr.galloc_chunk_info`](tables-views-functions/sequences/#bdrgalloc_chunk_info).
+[`bdr.galloc_chunk_info`](/pgd/latest/reference/tables-views-functions/sequences#bdrgalloc_chunk_info).
 
 * Node `Node1` is using range from `333` to `2000333`.
 
@@ -442,7 +442,7 @@ The internal contents of v1 and v2 aren't compatible. As such, the
 functions to manipulate them also aren't compatible. The v2 of `KSUUID` also
 no longer stores the `UUID` version number.
 
-See [KSUUID v2 functions](tables-views-functions/sequences/#ksuuid-v2-functions) and [KSUUID v1 functions](tables-views-functions/sequences/#ksuuid-v1-functions) in the PGD reference.
+See [KSUUID v2 functions](/pgd/latest/reference/tables-views-functions/sequences/#ksuuid-v2-functions) and [KSUUID v1 functions](/pgd/latest/reference/tables-views-functions/sequences/#ksuuid-v1-functions) in the PGD reference.
 
 ### Step and offset sequences
 
@@ -504,6 +504,6 @@ a one-row table that isn't part of a replication set to store a different
 value in each node.
 
 ## See also
-* [Global Sequence management interfaces](tables-views-functions/sequences/)
-* [KSUUID v2 functions](tables-views-functions/sequences/#ksuuid-v2-functions)
-* [KSUUID v1 functions](tables-views-functions/sequences/#ksuuid-v1-functions)
+* [Global Sequence management interfaces](/pgd/latest/reference/tables-views-functions/sequences/)
+* [KSUUID v2 functions](/pgd/latest/reference/tables-views-functions/sequences/#ksuuid-v2-functions)
+* [KSUUID v1 functions](/pgd/latest/reference/tables-views-functions/sequences/#ksuuid-v1-functions)
diff --git a/product_docs/docs/pgd/6/reference/tables-views-functions/sequences.mdx b/product_docs/docs/pgd/6/reference/tables-views-functions/sequences.mdx
@@ -252,7 +252,7 @@ This function executes only on the local node.
 
 ## KSUUID v2 functions
 
-Functions for working with `KSUUID` v2 data, K-Sortable UUID data. See also [KSUUID in the sequences documentation](../sequences/#ksuuids).
+Functions for working with `KSUUID` v2 data, K-Sortable UUID data. See also [KSUUID in the sequences documentation](/pgd/latest/reference/sequences/#ksuuids).
 
 ### `bdr.gen_ksuuid_v2`
 
@@ -314,7 +314,7 @@ This function executes only on the local node.
 
 ## KSUUID v1 functions
 
-Functions for working with `KSUUID` v1 data, K-Sortable UUID data(v1). Deprecated - See [KSUUID in the sequences documentation](../sequences/#ksuuids) for details.
+Functions for working with `KSUUID` v1 data, K-Sortable UUID data(v1). Deprecated - See [KSUUID in the sequences documentation](/pgd/latest/reference/sequences#ksuuids) for details.
 
 
 ### `bdr.gen_ksuuid`
