From c943d97292e1ddab38df0091f0d287e4c4667993 Mon Sep 17 00:00:00 2001 From: Betsy Gitelman Date: Thu, 6 Jun 2024 17:08:15 -0400 Subject: [PATCH] Additional edits to first set of PGD edits --- .../pgd/5/ddl/ddl-managing-with-pgd-replication.mdx | 8 ++++---- product_docs/docs/pgd/5/ddl/ddl-overview.mdx | 12 +++++------- 2 files changed, 9 insertions(+), 11 deletions(-) diff --git a/product_docs/docs/pgd/5/ddl/ddl-managing-with-pgd-replication.mdx b/product_docs/docs/pgd/5/ddl/ddl-managing-with-pgd-replication.mdx index be3edb13c30..c1fe779c19e 100644 --- a/product_docs/docs/pgd/5/ddl/ddl-managing-with-pgd-replication.mdx +++ b/product_docs/docs/pgd/5/ddl/ddl-managing-with-pgd-replication.mdx @@ -8,8 +8,8 @@ navTitle: Managing with replication Minimizing the impact of DDL is good operational advice for any database. These points become even more important with PGD: -- To minimize the impact of DDL, make transactions performing DDL short, - don't combine them with lots of row changes, and avoid long-running +- To minimize the impact of DDL, make transactions performing DDL short. + Don't combine them with lots of row changes, and avoid long-running foreign key or other constraint rechecks. - For `ALTER TABLE`, use `ADD CONSTRAINT NOT VALID` followed by another @@ -37,7 +37,7 @@ INDEX CONCURRENTLY`, noting that DDL replication must be disabled for the whole session because `CREATE INDEX CONCURRENTLY` is a multi-transaction command. Avoid `CREATE INDEX` on production systems since it prevents writes while it executes. -`REINDEX` is replicated in versions up to 3.6 but not with PGD 3.7 or later. +`REINDEX` is replicated in versions 3.6 and earlier but not with PGD 3.7 or later. Avoid using `REINDEX` because of the AccessExclusiveLocks it holds. Instead, use `REINDEX CONCURRENTLY` (or `reindexdb --concurrently`), @@ -107,7 +107,7 @@ by turning [`bdr.ddl_replication`](/pgd/latest/reference/pgd-settings#bdrddl_rep PGD prevents some DDL statements from running when it's active on a database. This protects the consistency of the system by disallowing statements that can't be replicated correctly or for which replication -isn't yet supported. +isn't yet supported. If a statement isn't permitted under PGD, you can often find another way to do the same thing. For example, you can't do an `ALTER TABLE`, diff --git a/product_docs/docs/pgd/5/ddl/ddl-overview.mdx b/product_docs/docs/pgd/5/ddl/ddl-overview.mdx index c6737253aab..aec5291d0ed 100644 --- a/product_docs/docs/pgd/5/ddl/ddl-overview.mdx +++ b/product_docs/docs/pgd/5/ddl/ddl-overview.mdx @@ -32,7 +32,7 @@ comes to DDL replication. Treating it the same is the most common issue with PGD. The main difference from table replication is that DDL replication doesn't -replicate the result of the DDL but the statement itself. This works +replicate the result of the DDL. Instead, it replicates the statement. This works very well in most cases, although it introduces the requirement that the DDL must execute similarly on all nodes. A more subtle point is that the DDL must be immutable with respect to all datatype-specific parameter settings, @@ -59,10 +59,10 @@ PGD offers three levels of protection against those problems: `ddl_locking = 'all'` is the strictest option and is best when DDL might execute from any node concurrently and you want to ensure correctness. This is the default. -`ddl_locking = 'dml'` is an option that is only safe when you execute -DDL from one node at any time. You should only use this setting -if you can completely control where DDL is executed. Executing DDL from a single node -it ensures that there are no inter-node conflicts. Intra-node conflicts are already +`ddl_locking = 'dml'` is an option that is safe only when you execute +DDL from one node at any time. Use this setting only +if you can completely control where DDL is executed. Executing DDL from a single node +ensures that there are no inter-node conflicts. Intra-node conflicts are already handled by PostgreSQL. `ddl_locking = 'off'` is the least strict option and is dangerous in general use. @@ -71,9 +71,7 @@ it a useful option when creating a new and empty database schema. These options can be set only by the bdr_superuser, by the superuser, or in the `postgres.conf` configuration file. - When using the [`bdr.replicate_ddl_command`](/pgd/latest/reference/functions#bdrreplicate_ddl_command), you can set this parameter directly with the third argument, using the specified [`bdr.ddl_locking`](/pgd/latest/reference/pgd-settings#bdrddl_locking) setting only for the DDL commands passed to that function. -