added some bold on commit scope callouts.

EnterpriseDB · Jan 14, 2025 · 9ba82c6 · 9ba82c6
1 parent 3be7049
commit 9ba82c6
Showing 1 changed file with 4 additions and 4 deletions.
diff --git a/product_docs/docs/pgd/5.6/overview/basic-architecture.mdx b/product_docs/docs/pgd/5.6/overview/basic-architecture.mdx
@@ -92,10 +92,10 @@ PGD allows for selective replication, enabling users to replicate only a subset
 
 With commit scopes, PGD also provides configurable durability. Accordingly, durability can be increased from the default asynchronous behavior and tuned using various configurable commit scopes: 
 
-- Synchronous Commit: Works a lot like PostgreSQL’s synchronous_commit option in its underlying operation—requires writing to at least one other node at COMMIT time, but can be tuned to require all nodes.
+- **Synchronous Commit**: Works a lot like PostgreSQL’s synchronous_commit option in its underlying operation—requires writing to at least one other node at COMMIT time, but can be tuned to require all nodes.
 
-- CAMO (Commit at most once): Works by tracking each transaction with a unique ID and using a pair of nodes to confirm the transaction's outcome, ensuring the application knows whether to retry the transaction or not.
+- **CAMO** (Commit at most once): Works by tracking each transaction with a unique ID and using a pair of nodes to confirm the transaction's outcome, ensuring the application knows whether to retry the transaction or not.
 
-- Group Commit: An experimental commit scope, the goal of which is to protect against data loss in case of single node failures of temporary outages by requiring more than one PGD node to successfully confirm a transaction at COMMIT time.
+- **Group Commit**: An experimental commit scope, the goal of which is to protect against data loss in case of single node failures of temporary outages by requiring more than one PGD node to successfully confirm a transaction at COMMIT time.
 
-- Lag Control: If replication is running outside of set limits (taking too long for another node to be replicated to), a delay is injected into the node that originally received the transaction, slowing things down until other nodes have caught up.
+- **Lag Control**: If replication is running outside of set limits (taking too long for another node to be replicated to), a delay is injected into the node that originally received the transaction, slowing things down until other nodes have caught up.