diff --git a/product_docs/docs/pgd/5.6/conflict-management/conflicts/02_types_of_conflict.mdx b/product_docs/docs/pgd/5.6/conflict-management/conflicts/02_types_of_conflict.mdx index 1e99c4a5f61..2467902a632 100644 --- a/product_docs/docs/pgd/5.6/conflict-management/conflicts/02_types_of_conflict.mdx +++ b/product_docs/docs/pgd/5.6/conflict-management/conflicts/02_types_of_conflict.mdx @@ -33,13 +33,17 @@ You can effectively eliminate this type of conflict by using [global sequences]( ### INSERT operations that violate UNIQUE or EXCLUDE constraints -An `INSERT`/`INSERT` conflict can violate more than one `UNIQUE` constraint, of which one might be the `PRIMARY KEY`. -With the addition of `EXCLUDE` constraint support in PGD 5.6, an `INSERT`/`INSERT`conflict can also violate one or more `EXCLUDE` constraints. +An `INSERT`/`INSERT` conflict can violate more than one `UNIQUE` constraint, one of which might be the `PRIMARY KEY`. +With the addition of `EXCLUDE` constraint support in PGD 5.6, an `INSERT`/`INSERT`conflict can also violate one or more `EXCLUDE` constraints. -If a new row violates more than one `UNIQUE` constraint and that results in a conflict against more than one other row, or a new row violates more than one `EXCLUDE` constraint or a single `EXCLUDE` constraint, either of which results in a conflict against more than one other row, then applying the replication change produces a `multiple_unique_conflicts` conflict. +In either of the following cases, applying the replication change produces a `multiple_unique_conflicts` conflict. Both of these cases result in a conflict against more than one other row. -In case of such a conflict, you must remove some rows for replication to continue. -Depending on the resolver setting for `multiple_unique_conflicts`, the apply process either exits with error, skips the incoming row, or deletes some of the rows. +- If a new row violates more than one `UNIQUE` constraint and that results in a conflict against more than one other row. + +- If a new row violates more than one `EXCLUDE` constraint or a single `EXCLUDE` constraint. + +In case of such a conflict, for replication to continue, you must remove some rows. +Depending on the resolver setting for `multiple_unique_conflicts`, the apply process either exits with an error, skips the incoming row, or deletes some of the rows. The deletion tries to preserve the row with the correct `PRIMARY KEY` and delete the others. !!! Warning diff --git a/product_docs/docs/pgd/5.6/ddl/ddl-command-handling.mdx b/product_docs/docs/pgd/5.6/ddl/ddl-command-handling.mdx index 9fdf01482ac..1e28441c179 100644 --- a/product_docs/docs/pgd/5.6/ddl/ddl-command-handling.mdx +++ b/product_docs/docs/pgd/5.6/ddl/ddl-command-handling.mdx @@ -228,7 +228,7 @@ under the following table. | VACUUM | Y | N | N | -## Command Notes +## Command notes
### ALTER SEQUENCE @@ -253,11 +253,11 @@ Some variants of `ALTER TABLE` currently aren't allowed on a PGD node: - `ADD COLUMN ... DEFAULT (non-immutable expression)` — This is not allowed because it currently results in different data on different nodes. See [Adding a column](ddl-workarounds/#adding-a-column) for a suggested workaround. - This can be overriden using `bdr.permit_unsafe_commands` if user is sure the command is + You can override this behavior using `bdr.permit_unsafe_commands` if you're sure the command is safe. - `ALTER COLUMN ... SET STORAGE external` — Is rejected if the column is one of the columns of the replica identity for the table. - This can be overriden using `bdr.permit_unsafe_commands` if user is sure the command is + You can override this behavior using `bdr.permit_unsafe_commands` if you're sure the command is safe. - `RENAME` — Can't rename an Autopartitioned table. - `SET SCHEMA` — Can't set the schema of an Autopartitioned table. diff --git a/product_docs/docs/pgd/5.6/index.mdx b/product_docs/docs/pgd/5.6/index.mdx index 63d4b6b1c99..7e1a1c41d1b 100644 --- a/product_docs/docs/pgd/5.6/index.mdx +++ b/product_docs/docs/pgd/5.6/index.mdx @@ -74,7 +74,7 @@ the peer nodes only after the local commit. You can configure additional levels ## Compatibility -EDB Postgres Distributed 5 is compatible with PostgreSQL, EDB Postgres Extended, and EDB Postgres Advanced versions 12-17. See the [compatibility](compatibility) section for more details, including compatibility with different operating systems and architectures. +EDB Postgres Distributed 5 is compatible with PostgreSQL, EDB Postgres Extended, and EDB Postgres Advanced versions 12-17. See [Compatibility](compatibility) for more details, including information about compatibility with different operating systems and architectures. For feature compatibility with compatible servers, see [Choosing a Postgres distribution](planning/choosing_server). --- diff --git a/product_docs/docs/pgd/5.6/reference/functions.mdx b/product_docs/docs/pgd/5.6/reference/functions.mdx index a4dc42e6251..24c66c05ddf 100644 --- a/product_docs/docs/pgd/5.6/reference/functions.mdx +++ b/product_docs/docs/pgd/5.6/reference/functions.mdx @@ -314,9 +314,9 @@ If no node name is supplied (by passing NULL), the function waits until all the We recommend using this function if you are using [Optimized Topology](../nodes/subscriber_only/optimizing-so) instead of [`bdr.wait_slot_confirm_lsn`](/pgd/5.6/reference/functions#bdrwait_slot_confirm_lsn). -This is because in an Optimized Topology, not all nodes have replication slots, so the function `bdr.wait_slot_confirm_lsn` might not work as expected. `bdr.wait_node_confirm_lsn` is designed to work with nodes that don't have replication slots, using alternative straegies to determine the progress of a node. +This is because in an Optimized Topology, not all nodes have replication slots, so the function `bdr.wait_slot_confirm_lsn` might not work as expected. `bdr.wait_node_confirm_lsn` is designed to work with nodes that don't have replication slots, using alternative strategies to determine the progress of a node. -If a node is currently down, isn't updating or is simply not able to be connected to, the wait will continue indefinately. To avoid this, set the statement_timeout to the maximum amount of time you are prepared to wait. +If a node is currently down, isn't updating, or simply can't be connected to, the wait will continue indefinitely. To avoid this condition, set the statement_timeout to the maximum amount of time you are prepared to wait. #### Synopsis @@ -432,7 +432,7 @@ bdr.replicate_ddl_command(ddl_cmd text, | Parameter | Description | | --------- | ----------- | | `ddl_cmd` | DDL command to execute. | -| `replication_sets` | An array of replication set names to apply the `ddlcommand` to. If NULL (or the function is only passed the `ddlcommand`), this is set to the active PGD groups's default replication set. | +| `replication_sets` | An array of replication set names to apply the `ddlcommand` to. If NULL (or the function is passed only the `ddlcommand`), this parameter is set to the active PGD groups's default replication set. | | `ddl_locking` | A string that sets the [`bdr.ddl_locking`](/pgd/latest/reference/pgd-settings#bdrddl_locking) value while replicating. Defaults to the GUC value for `bdr.ddl_locking` on the local system that's running `replicate_ddl_command`. | | `execute_locally` | A Boolean that determines whether the DDL command executes locally. Defaults to true. | @@ -1006,7 +1006,7 @@ bdr.wal_sender_stats() | Column name | Description | |---------------------|-------------------------------------------------------------------------------------| -| `pid` | PID of the WAL sender. (corresponds to the `pid` column of `pg_stat_replication`). | +| `pid` | PID of the WAL sender. (Corresponds to the `pid` column of `pg_stat_replication`). | | `is_using_lcr` | Whether the WAL sender is sending LCR files. | | `decoder_slot_name` | Name of the decoder replication slot. | | `lcr_file_name` | Name of the current LCR file. | @@ -1029,7 +1029,7 @@ bdr.get_decoding_worker_stat() | Column name | Description | |-------------|-------------| -| `pid` | The PID of the decoding worker (corresponds to the column `active_pid` in `pg_replication_slots`). | +| `pid` | The PID of the decoding worker. (Corresponds to the column `active_pid` in `pg_replication_slots`.) | | `decoded_upto_lsn` | LSN up to which the decoding worker read transactional logs. | | `waiting` | Whether the decoding worker is waiting for new WAL. | | `waiting_for_lsn` | The LSN of the next expected WAL. | diff --git a/product_docs/docs/pgd/5.6/reference/nodes.mdx b/product_docs/docs/pgd/5.6/reference/nodes.mdx index f54de4cd385..b7a7bcade24 100644 --- a/product_docs/docs/pgd/5.6/reference/nodes.mdx +++ b/product_docs/docs/pgd/5.6/reference/nodes.mdx @@ -114,9 +114,9 @@ present but empty. ### `bdr_config` -This command-line utility allows the user to examine the configuration of a PGD installation. -It is analogous to the `pg_config` utility that comes with PostgreSQL. It can be used to assist -in trouble-shooting and support. +This command-line utility allows you to examine the configuration of a PGD installation. +It is analogous to the `pg_config` utility that comes with PostgreSQL. You can use it to assist +in troubleshooting and support. #### Synopsis @@ -129,7 +129,7 @@ bdr_config [OPTION] ... | Option           | Description | | --- | --- | | `--all` | Show all the keys and values in the configuration. | -| `--version` | Show only the BDR version related keys and values. This include the full version of the BDR extension, the Postgres version and flavor it is running against and the BDRPG and BDR plugin API versions. | +| `--version` | Show only the BDR version related keys and values. This includes the full version of the BDR extension, the Postgres version and flavor it is running against, and the BDRPG and BDR plugin API versions. | | `--debug` | Show only the BDR debug keys and values, including build information and feature enablement. | #### Example