Stubbed out the concepts section with some intros and links

djw-m · djw-m · commit db1c3da9278b · 2025-06-09T16:56:28.000+01:00
Signed-off-by: Dj Walker-Morgan &lt;dj.walker-morgan@enterprisedb.com&gt;
diff --git a/product_docs/docs/pgd/6/concepts/advanced-durability.mdx b/product_docs/docs/pgd/6/concepts/advanced-durability.mdx
@@ -0,0 +1,4 @@
+---
+title: Advanced Durability
+---
+
diff --git a/product_docs/docs/pgd/6/concepts/commit-scopes.mdx b/product_docs/docs/pgd/6/concepts/commit-scopes.mdx
@@ -0,0 +1,4 @@
+---
+title: Commit Scopes
+---
+
diff --git a/product_docs/docs/pgd/6/concepts/conflict-management.mdx b/product_docs/docs/pgd/6/concepts/conflict-management.mdx
@@ -0,0 +1,9 @@
+---
+title: Conflict Management
+---
+
+With PGD Expanded, the presence of multiple writers leads to the possibility, or even the likelihood, of conflicts. Changes to the same rows from different nodes can arrive on a node at any time. 
+PGD Expanded provides a conflict management system that allows you to define how conflicts are handled in your distributed database environment.
+
+Read more about conflict management in the [Conflict Management reference](/pgd/latest/reference/conflict-management/) documentation.
+
diff --git a/product_docs/docs/pgd/6/concepts/connection-management.mdx b/product_docs/docs/pgd/6/concepts/connection-management.mdx
@@ -0,0 +1,11 @@
+---
+title: Connection Management
+---
+
+To ensure that clients can connect to the right nodes in the distributed cluster, EDB Postgres Distributed (PGD) provides a connection management system that allows clients to connect to the appropriate nodes based on their needs.
+
+This system is designed to ensure that clients can access the data they need while maintaining the performance and availability of the cluster. 
+Unlike Proxy systems, this connection management system is built into the database instance itself, allowing for more efficient and reliable connections.
+
+Read more about the [Connection Management feature in PGD](/pgd/latest/reference/connection-management/) for full details.
+
diff --git a/product_docs/docs/pgd/6/concepts/durability.mdx b/product_docs/docs/pgd/6/concepts/durability.mdx
@@ -0,0 +1,8 @@
+---
+title: Durability
+---
+
+How does EDB Postgres Distributed (PGD) ensure durability of transactions?
+
+Durability can be defined as the guarantee that once a transaction has been committed, it will remain so, even in the event of a system failure. In EDB Postgres Distributed (PGD), durability is achieved through a combination of write-ahead logging (WAL) and replication, in combination with the commit scopes available in the cluster and the configuration of the nodes in the cluster.
+
diff --git a/product_docs/docs/pgd/6/concepts/expanded-commit-scopes.mdx b/product_docs/docs/pgd/6/concepts/expanded-commit-scopes.mdx
@@ -0,0 +1,6 @@
+---
+title: Expanded Commit Scopes
+---
+
+PGD Expanded allows you to define commit scopes that are more granular or more customised than the standard pre-defined commit scopes available in PGD. This feature is particularly useful for applications that require specific commit behaviors or need to manage complex transaction scenarios.
+
diff --git a/product_docs/docs/pgd/6/concepts/geo-distributed-clusters b/product_docs/docs/pgd/6/concepts/geo-distributed-clusters
@@ -0,0 +1,6 @@
+---
+title: Geo-Distributed Clusters
+---
+
+Geo-distributed clusters are a powerful feature of PGD which allow you to create a distributed database system that spans multiple geographic locations. This setup is particularly useful for applications that require high availability, low latency, and disaster recovery across different regions. As this feature needs multiple write nodes and multiple distributed groups, it is only available in PGD Expanded.
+
diff --git a/product_docs/docs/pgd/6/concepts/index.mdx b/product_docs/docs/pgd/6/concepts/index.mdx
@@ -3,24 +3,32 @@ title: PGD concepts explained
 navTitle: PGD concepts explained
 description: The concepts behind EDB Postgres Distributed (PGD) 6.0 and how they work in practice.
 navigation:
+- replication
+- nodes-and-groups
+- connection-management
+- locking
+- durability
+- commit-scopes
+- lag-control
+- expanded-commit-scopes
+- geo-distributed-clusters
+- advanced-durability
+- conflict-management
 ---
 
 ## PGD concepts
 
 * [Replication](replication)
 * [Nodes and groups](nodes-and-groups)
-
-<!--->
+* [Connection management](connection-management)
 * [Locking](locking)
 * [Durability](durability)
 * [Commit scopes](commit-scopes)
 * [Lag Control](lag-control)
+
 ## PGD Expanded concepts
-* [Commit scopes for Exp](expanded-commit-scopes)
+
+* [Commit scopes for PGD Expanded](expanded-commit-scopes)
 * [Geo-distributed clusters](geo-distributed-clusters)
 * [Advanced durability](advanced-durability)
-* [Custom configurations](custom-configurations)
 * [Conflict management](conflict-management)
-* [Replication sets](replication-sets)
-
-</--->
diff --git a/product_docs/docs/pgd/6/concepts/lag-control.mdx b/product_docs/docs/pgd/6/concepts/lag-control.mdx
@@ -0,0 +1,11 @@
+---
+title: Lag Control
+---
+
+When a node is lagging behind the rest of the cluster, it can cause issues with data consistency and availability. Lag control is a mechanism to manage this situation by ensuring that the lagging node does not disrupt the overall performance of the cluster.
+
+## Lag Control in PGD
+
+When lag is detected in PGD, the Lag Control feature is activated. This feature is designed to manage the lagging node and ensure that it does not disrupt the overall performance of the cluster. It does this by transparently and temporarily slowing client connections, introducing a commit delay to clients. This allows the lagging node to catch up with the rest of the cluster without impacting the performance of the other nodes.
+
+Read more about the [Lag Control feature in PGD](/pgd/latest/reference/commit-scopes/lag-control/) for full details.
diff --git a/product_docs/docs/pgd/6/concepts/locking.mdx b/product_docs/docs/pgd/6/concepts/locking.mdx
@@ -0,0 +1,26 @@
+---
+title: Locking
+---
+
+To prevent conflicts between various operations in the cluster, PGD uses a distributed locking mechanism to ensure the only one node can perform a specific operation at a time. 
+
+This is particularly important in a distributed environment where multiple nodes may attempt to modify the same data concurrently.
+As PGD Essential is a single-write node cluster, it does not have to deal with distributed locking in the same way, as there is only one node that can perform write operations at any time.
+PGD Expaned, however, has multiple write nodes, and so it must will always use distributed locking to ensure integerity.
+
+## Kinds of Locks
+
+PGD uses several kinds of locks to manage concurrent access to data and resources in the cluster:
+
+### DDL locking
+
+DDL (Data Definition Language) locks are used to manage access to database objects such as tables, indexes, and schemas. When a DDL operation is performed, a lock is acquired on the object being modified to prevent other operations from interfering with the change. This ensures that the structure of the database remains consistent and prevents conflicts between concurrent DDL operations. Read more about DDL locking in the [DDL Locking reference](/pgd/latest/reference/ddl/ddl-locking/) documentation.
+
+### DML locking
+
+DML locking is closly related to DDL locking and is used to add an extra layer of protection to a DDL operation being replicated by also halting any DML operations that would conflict with the DDL operation. Again, this is only needed in a multi-write node cluster, and is not used in PGD Essential. 
+
+### Which locks are used when?
+
+The locks used in PGD depend on the type of operation being performed and the configuration of the cluster. In general, DDL locks are used for schema changes, while DML locks are used for data modifications. A full list of the locks used in PGD can be found in the [DDL command handling matrix](/pgd/latest/reference/ddl/ddl-command-handling) documentation.
+
diff --git a/product_docs/docs/pgd/6/concepts/nodes-and-groups.mdx b/product_docs/docs/pgd/6/concepts/nodes-and-groups.mdx
@@ -38,6 +38,14 @@ Their role is to provide a deadlock breaking vote in the event of a group of dat
 
 Witness nodes do not participate in the normal data replication process, but they can be used to help resolve conflicts and ensure that the cluster remains available even in the face of network partitions or other failures.
 
+## Subscriber-only Nodes
+
+Subscriber-only nodes are used to provide a read-only replica of the data in the cluster. In PGD 6, you can configure a subscriber-only node as a member of a data group or a member of a subscriber-only group. The latter has no write leader node, and all nodes in the group are read-only and allow for some optional optimizations in the replication process. The former allows for a read-only replica of the data in the group, but it does not allow for any optimizations in the replication process.
+
+A subscriber-only node can be used to offload read queries from the write leader node, which can help to improve performance and reduce the load on the write leader node. It can also be used to provide a read-only replica of the data in the cluster for reporting or analytics purposes. You can connect to the read-only nodes like this using the connection manager's read-only connection string, which will direct the connections to the pool of read-only nodes in the cluster.
+
 ## Logical Standby Nodes
 
-Logical standby nodes are used to provide a read-only replica of the data in the cluster.
+Logical standby nodes are used to provide a read-only replica of the data in the cluster. They are similar to subscriber-only nodes, but they are designed to be more flexible and can be used in a wider range of scenarios.
+
+

-Original file line number
+Diff line change
@@ @@ -0,0 +1,4 @@ @@
 +---
 +title: Advanced Durability
 +---
++