Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Edits to DOCS-1076 - Documenting PGD 5.6.1 #6210 #6298

Merged
merged 4 commits into from
Dec 5, 2024
Merged
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was a very long and hard-to-follow sentence. Please check this revision.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm happy. @jpe442 want to look?

The deletion tries to preserve the row with the correct `PRIMARY KEY` and delete the others.

!!! Warning
Expand Down
6 changes: 3 additions & 3 deletions product_docs/docs/pgd/5.6/ddl/ddl-command-handling.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -228,7 +228,7 @@ under the following table.
| VACUUM | Y | N | N |


## Command Notes
## Command notes
<div id='bdr_ddl_allowed_AlterSeqStmt'></div>

### ALTER SEQUENCE
Expand All @@ -253,11 +253,11 @@ Some variants of `ALTER TABLE` currently aren't allowed on a PGD node:
- `ADD COLUMN ... DEFAULT (non-immutable expression)` &mdash; 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` &mdash; 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` &mdash; Can't rename an Autopartitioned table.
- `SET SCHEMA` &mdash; Can't set the schema of an Autopartitioned table.
Expand Down
2 changes: 1 addition & 1 deletion product_docs/docs/pgd/5.6/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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 the [Compatibility](compatibility) for more details, including compatibility with different operating systems and architectures.
ebgitelman marked this conversation as resolved.
Show resolved Hide resolved
For feature compatibility with compatible servers, see [Choosing a Postgres distribution](planning/choosing_server).

---
2 changes: 1 addition & 1 deletion product_docs/docs/pgd/5.6/known_issues.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -51,6 +51,6 @@ To modify a commit scope safely, use [`bdr.alter_commit_scope`](/pgd/latest/refe

- DDL run in serializable transactions can face the error: `ERROR: could not serialize access due to read/write dependencies among transactions`. A workaround is to run the DDL outside serializable transactions.

- The EPAS 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.
- The EPAS 17 data type [`BFILE`](/epas/latest/reference/sql_reference/02_data_types/03a_bfiles/) isn't currently supported. This is due to `BFILE` being a file reference that's stored in the database, and the file itself is stored outside the database and not replicated.

Details of other design or implementation [limitations](planning/limitations) are also available.
10 changes: 5 additions & 5 deletions product_docs/docs/pgd/5.6/reference/functions.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down Expand Up @@ -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. |

Expand Down Expand Up @@ -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. |
Expand All @@ -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. |
Expand Down
8 changes: 4 additions & 4 deletions product_docs/docs/pgd/5.6/reference/nodes.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -129,7 +129,7 @@ bdr_config [OPTION] ...
| Option&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | 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
Expand Down