diff --git a/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/pgd_defaults_ba.mdx b/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/pgd_defaults_ba.mdx index ed789386dce..7e10cdd129c 100644 --- a/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/pgd_defaults_ba.mdx +++ b/advocacy_docs/edb-postgres-ai/cloud-service/references/distributed_high_availability/pgd_defaults_ba.mdx @@ -6,7 +6,7 @@ deepToC: true ## Commit scope -[Commit scopes](/pgd/latest/commit-scopes/) in PGD are a set of rules that describe the behavior of the system as transactions are committed. Because they define how transactions are replicated across a distributed database, they have an effect on consistency, durability, and performance. +[Commit scopes](/pgd/latest/commit-scopes/commit-scopes/) in PGD are a set of rules that describe the behavior of the system as transactions are committed. Because they define how transactions are replicated across a distributed database, they have an effect on consistency, durability, and performance. The actual behavior depends on the kind of commit scope a commit scope's rule uses: [Group Commit](/pgd/latest/commit-scopes/group-commit/), [Commit At Most Once](/pgd/latest/commit-scopes/camo/), [Lag Control](/pgd/latest/commit-scopes/lag-control/), [Synchronous Commit](/pgd/latest/commit-scopes/synchronous_commit/), or a combination of these. diff --git a/product_docs/docs/pgd/5.6/commit-scopes/camo.mdx b/product_docs/docs/pgd/5.6/commit-scopes/camo.mdx index 226ff31810b..13fccf17ad2 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/camo.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/camo.mdx @@ -43,7 +43,7 @@ To use CAMO, an application must issue an explicit `COMMIT` message as a separat ## Configuration -Configuration of CAMO happens through [commit scopes](commit-scopes). +See the[`CAMO`](/pgd/latest/reference/commit-scopes/#camo) commit scope reference for configuration parameters. ## Confirmation @@ -58,7 +58,6 @@ Configuration of CAMO happens through [commit scopes](commit-scopes). See the CAMO section of [Limitations](limitations#camo). - ## Failure scenarios Different failure scenarios occur in different configurations. diff --git a/product_docs/docs/pgd/5.6/commit-scopes/commit-scope-rules.mdx b/product_docs/docs/pgd/5.6/commit-scopes/commit-scope-rules.mdx index 0bd594459ed..150e8474c8c 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/commit-scope-rules.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/commit-scope-rules.mdx @@ -61,6 +61,12 @@ If you're familiar with PostgreSQL's `synchronous_standby_names` feature, be awa Currently, there are four commit scope kinds. The following is a summary, with links to more details. +### `SYNCHRONOUS_COMMIT` + +Synchronous Commit is a commit scope option that's designed to behave like the native Postgres `synchronous_commit` option, but is usable from within the commit scope environment. Unlike `GROUP COMMIT`, it's a synchronous non-two-phase commit operation. Like `GROUP COMMIT`, it supports an optional `DEGRADE ON` clause. The commit scope group that comes before this option controls the groups and confirmation requirements the `SYNCHRONOUS_COMMIT` uses. + +For more details, see [`SYNCHRONOUS_COMMIT`](synchronous_commit). + ### `GROUP COMMIT` Group Commit is a synchronous, two-phase commit that's confirmed according to the requirements of the commit scope group. `GROUP COMMIT` has options that control: @@ -83,12 +89,6 @@ With Lag Control, when the system's replication performance exceeds specified li For more details, see [`LAG CONTROL`](lag-control). -### `SYNCHRONOUS_COMMIT` - -Synchronous Commit is a commit scope option that's designed to be like the legacy `synchronous_commit` option, but it's accessible in the commit scope environment. Unlike `GROUP COMMIT`, it's a synchronous non-two-phase commit operation, and it has no parameters. The commit scope group that comes before this option controls the groups and confirmation requirements the `SYNCHRONOUS_COMMIT` uses. - -For more details, see [`SYNCHRONOUS_COMMIT`](synchronous_commit). - ## Combining rules Commit scope rules are composed of one or more operations that work in combination. Use an AND to form a single rule. For example: diff --git a/product_docs/docs/pgd/5.6/commit-scopes/commit-scopes.mdx b/product_docs/docs/pgd/5.6/commit-scopes/commit-scopes.mdx index 1249265b242..af899029ac6 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/commit-scopes.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/commit-scopes.mdx @@ -4,7 +4,7 @@ title: Commit scopes Commit scopes give applications granular control about durability and consistency of EDB Postgres Distributed. -A commit scope is a set of rules that describes the behavior of the system as transactions are committed. The actual behavior depends on which a kind of commit scope a commit scope's rule uses [Group Commit](group-commit), [Commit At Most Once](camo), [Lag Control](lag-control), [Synchronous Commit](synchronous_commit) or combination of these. +A commit scope is a set of rules that describes the behavior of the system as transactions are committed. The actual behavior depends on which a kind of commit scope a commit scope's rule uses [Synchronous Commit](synchronous_commit), [Group Commit](group-commit), [Commit At Most Once](camo), [Lag Control](lag-control), or combination of these. While most commit scope kinds control the processing of the transaction, Lag Control is the exception as it dynamically regulates the performance of the system in response to replication operations being slow or queued up. It is typically used, though, in combination with other commit scope kinds @@ -173,6 +173,4 @@ SELECT bdr.alter_node_group_option( config_key := 'default_commit_scope', config_value := 'example_scope' ); -``` - - +``` \ No newline at end of file diff --git a/product_docs/docs/pgd/5.6/commit-scopes/degrading.mdx b/product_docs/docs/pgd/5.6/commit-scopes/degrading.mdx new file mode 100644 index 00000000000..10acf8c4db5 --- /dev/null +++ b/product_docs/docs/pgd/5.6/commit-scopes/degrading.mdx @@ -0,0 +1,63 @@ +--- +title: Degrading commit scope rules +navTitle: Degrading +deepToC: true +--- + +`SYNCHRONOUS_COMMIT`, `GROUP COMMIT`, and `CAMO` each have the optional capability of degrading the requirements for transactions when particular performance thresholds are crossed. + +When a node is applying a transaction and that transaction times out, it can be useful to trigger a process of degrading the requirements of the transaction to be completed, rather than just rolling back. + +`DEGRADE ON` offers a route for gracefully degrading the commit scope rule of a transaction. At its simplest, `DEGRADE ON` takes a timeout and a second set of commit scope operations that the commit scope can gracefully degrade to. + +For instance, after 20ms or 30ms timeout, the requirements for satisfying a commit scope could degrade from `ALL (node_group_name) GROUP COMMIT` to `MAJORITY (node_group_name) GROUP COMMIT`, making the transactions apply more steadily. + +You can also require that the write leader be the originator of a transaction in order for the degrade clause to be triggered. This can be helpful in "split brain scenarios" where you have, say, 2 data nodes and a witness node. Supposing there is a network split between the two data nodes and you have connections to both of the data nodes, only one of them will be allowed to degrade, because only one of them will be elected leader through the raft election with the witness node. + +## Behavior + +There are two parts to how the generalized `DEGRADE` clause behaves as it is applied to transactions. + +Once during the commit, while the commit being processed is waiting for responses that satisfy the commit scope rule, PGD checks for a timeout and, if the timeout has expired, the commit being processed is reconfigured to wait for the commit scope rule in the `DEGRADE` clause. In fact, by this point, the commit scope rule in the `DEGRADE` clause might already be satisfied. + +This mechanism alone is insufficient for the intended behavior, as this alone would mean that every transaction—even those that were certain to degrade due to connectivity issues—must wait for the timeout to expire before degraded mode kicks in, which would severely affect performance in such degrading-cluster scenarios. + +To avoid this, the PGD manager process also periodically (every 5s) checks the connectivity and apply rate (the one in [bdr.node_replication_rates](/pgd/latest/reference/catalogs-visible/#bdrnode_replication_rates)) and if there are commit scopes that would degrade at that point based on the current state of replication, they will be automatically degraded—such that any transaction using that commit scope when processing after that uses the degraded rule instead of waiting for timeout—until the manager process detects that replication is moving swiftly enough again. + +## SYNCHRONOUS_COMMIT and GROUP COMMIT + +Both `SYNCHRONOUS_COMMIT` and `GROUP COMMIT` have `timeout` and `require_write_lead` parameters, with defaults of `0` and `false` respectively. You should probably always set the `timeout`, as the default of `0` causes an instant degrade. You can also require that the write leader be the originator of the transaction in order to switch to degraded (again, default is `false`). + +Both `SYNCHRONOUS_COMMIT` and `GROUP COMMIT` also have options regarding which rule you can degrade to—which depends on which rule you are degrading from. + +First of all, you can degrade to asynchronous operation: + +```sql +ALL (left_dc) SYNCHRONOUS_COMMIT DEGRADE ON (timeout=20s) TO ASYNC +``` + +You can also degrade to a less restrictive commit group with the same commit scope kind (again as long as the kind is either `SYNCHRONOUS_COMMIT` or `GROUP COMMIT`). For instance, you can degrade as follows: + +```sql +ALL (left_dc) SYNCHRONOUS_COMMIT DEGRADE ON (timeout=20s) TO MAJORITY (left_dc) SYNCHRONOUS_COMMIT +``` + +or as follows: + +```sql +ANY 3 (left_dc) SYNCHRONOUS_COMMIT DEGRADE ON (timeout=20s) TO ANY 2 (left_dc) SYNCHRONOUS_COMMIT +``` + +But you cannot degrade from `SYNCHRONOUS_COMMIT` to `GROUP COMMIT` or the other way around. + +## CAMO + +While [CAMO](camo) supports both the same `timeout` and `require_write_lead` parameters (with the same defaults, `0` and `false` respectively), the options are simpler in that you can only degrade to asynchronous operation. + +```sql +ALL (left_dc) CAMO DEGRADE ON (timeout=20ms, require_write_lead=true) TO ASYNC +``` + +Again, you should set the `timeout` parameter, as the default is `0`. + + diff --git a/product_docs/docs/pgd/5.6/commit-scopes/group-commit.mdx b/product_docs/docs/pgd/5.6/commit-scopes/group-commit.mdx index d2c0498b8e1..54b08418def 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/group-commit.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/group-commit.mdx @@ -51,8 +51,7 @@ See the Group Commit section of [Limitations](limitations#group-commit). ## Configuration -To use Group Commit, first define a [commit scope](commit-scopes). The commit scope -determines the PGD nodes involved in the commit of a transaction. +`GROUP_COMMIT` supports optional `GROUP COMMIT` parameters, as well as `ABORT ON` and `DEGRADE ON` clauses. For a full description of configuration parameters, see the [GROUP_COMMIT](/pgd/latest/reference/commit-scopes/#group-commit) commit scope reference or for more regarding `DEGRADE ON` options in general, see the [Degrade options](degrading) section. ## Confirmation @@ -63,7 +62,6 @@ determines the PGD nodes involved in the commit of a transaction. `durable` | Confirms the transaction after all of its changes are flushed to disk. `visible` (default) | Confirms the transaction after all of its changes are flushed to disk and it's visible to concurrent transactions. - ## Behavior The behavior of Group Commit depends on the configuration applied by the commit diff --git a/product_docs/docs/pgd/5.6/commit-scopes/index.mdx b/product_docs/docs/pgd/5.6/commit-scopes/index.mdx index 907eebd50ea..dcf9e710893 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/index.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/index.mdx @@ -7,11 +7,12 @@ navigation: - commit-scopes - commit-scope-rules - comparing + - degrading - '# Commit Scope kinds' + - synchronous_commit - group-commit - camo - lag-control - - synchronous_commit - '# Working with' - administering - legacy-sync @@ -24,8 +25,8 @@ redirects: --- EDB Postgres Distributed (PGD) offers a range of synchronous modes to complement its -default asynchronous replication. These synchronous modes are configured through -commit scopes. Commit scopes are rules that define how operations are handled and when the system +default asynchronous replication. You use commit scopes to configure these synchronous modes. +Commit scopes are rules that define how PGD handles synchronous operations and when the system considers a transaction committed. ## Introducing @@ -34,18 +35,23 @@ considers a transaction committed. terminology that's used when discussing synchronous commits. * [Durability terminology](durabilityterminology) lists terms used around PGD's -durability options, including how nodes are referred to in replication. +durability options, including how to refer to nodes in replication. * [Commit scopes](commit-scopes) is a more in-depth look at the structure of commit scopes and how to define them for your needs. -* [Commit scope rules](commit-scope-rules) looks at the syntax of and how to formulate +* [Commit scope rules](commit-scope-rules) looks at the syntax of and how to compose a commit scope rule. -* [Comparing](comparing) compares how each option behaves. +* [Comparing durability options](comparing) compares how commit scope options behave with regard to durability. + +* [Degrading commit scope rules](degrading) shows how to set up a commit scope rule that can gracefully degrade to a lower setting in case of timeouts with a stricter setting. ## Commit scope kinds +* [Synchronous Commit](synchronous_commit) is a commit scope mechanism that works +in a similar fashion to legacy synchronous replication, but from within the commit scope framework. + * [Group Commit](group-commit) focuses on the Group Commit option, where you can define a transaction as done when a group of nodes agrees it's done. @@ -57,9 +63,6 @@ retrying. This ensures that their commits only happen at most once. dynamically throttle nodes according to the slowest node and regulates how far out of sync nodes may go when a database node goes out of service. -* [Synchronous Commit](synchronous_commit) examines a commit scope mechanism that works -in a similar fashion to legacy synchronous replication, but from within the commit scope framework. - ## Working with commit scopes * [Administering](administering) addresses how to manage a PGD cluster with Group Commit @@ -69,8 +72,6 @@ in use. that aren't currently supported or aren't possible. Refer to this before deciding on a durability strategy. -* [Legacy synchronous replication](legacy-sync) shows how traditional Postgres synchronous operations -can still be accessed under PGD. +* [Legacy synchronous replication](legacy-sync) shows how you can still access traditional Postgres synchronous operations under PGD. -* [Internal timing of operations](timing) compares legacy replication with PGD's async and synchronous -operations, especially the difference in the order by which transactions are flushed to disk or made visible. +* [Internal timing of operations](timing) compares legacy replication with PGD's async and synchronous operations, especially the difference in the order by which transactions are flushed to disk or made visible. diff --git a/product_docs/docs/pgd/5.6/commit-scopes/overview.mdx b/product_docs/docs/pgd/5.6/commit-scopes/overview.mdx index 94e6ffde9c8..4116925ed8d 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/overview.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/overview.mdx @@ -36,6 +36,8 @@ to applications that are related but can all be implemented individually: Commit scopes allow four kinds of controlling durability of the transaction: +- [Synchronous Commit](synchronous_commit): This kind of commit scope allows for a behavior where the origin node awaits a majority of nodes to confirm and behaves more like a native Postgres synchronous commit. + - [Group Commit](group-commit): This kind of commit scope controls which and how many nodes have to reach a consensus before the transaction is considered to be committable and at what stage of replication it can be considered committed. This option also @@ -48,8 +50,7 @@ Commit scopes allow four kinds of controlling durability of the transaction: - [Lag Control](lag-control): This kind of commit scope controls how far behind nodes can be in terms of replication before allowing commit to proceed. -- [PGD Synchronous Commit](synchronous_commit): This kind of commit scope allows for a behavior where the origin node awaits a majority of nodes to confirm and behaves more like a native Postgres synchronous commit. - +Synchronous commit, group commit, and CAMO each support [degrading commit scope rules](degrading), for even further control of durability. !!! Note Legacy synchronization availability For backward compatibility, PGD still supports configuring synchronous diff --git a/product_docs/docs/pgd/5.6/commit-scopes/synchronous_commit.mdx b/product_docs/docs/pgd/5.6/commit-scopes/synchronous_commit.mdx index 654adbbc933..3b853d7729a 100644 --- a/product_docs/docs/pgd/5.6/commit-scopes/synchronous_commit.mdx +++ b/product_docs/docs/pgd/5.6/commit-scopes/synchronous_commit.mdx @@ -1,9 +1,10 @@ --- -title: PGD Synchronous Commit +title: Synchronous Commit deepToC: true --- Commit scope kind: `SYNCHRONOUS_COMMIT` +alias: `SYNCHRONOUS COMMIT` ## Overview @@ -26,7 +27,7 @@ SELECT bdr.add_commit_scope( ## Configuration -`SYNCHRONOUS_COMMIT` has no parameters to configure. +`SYNCHRONOUS_COMMIT` supports the optional `DEGRADE ON` clause. See the [`SYNCHRONOUS_COMMIT`](/pgd/latest/reference/commit-scopes/#synchronous_commit) commit scope reference for specific configuration parameters or see [this section](degrading) regarding Degrade on options. ## Confirmation diff --git a/product_docs/docs/pgd/5.6/reference/commit-scopes.mdx b/product_docs/docs/pgd/5.6/reference/commit-scopes.mdx index f6519e499e0..cad01f87e18 100644 --- a/product_docs/docs/pgd/5.6/reference/commit-scopes.mdx +++ b/product_docs/docs/pgd/5.6/reference/commit-scopes.mdx @@ -7,7 +7,7 @@ rootisheading: false deepToC: true --- -Commit scopes are rules that determine how transaction commits and conflicts are handled within a PGD system. You can read more about them in [Durability](/pgd/latest/commit-scopes/). +Commit scopes are rules that determine how transaction commits and conflicts are handled within a PGD system. You can read more about them in [Commit Scopes](/pgd/latest/commit-scopes/). You can manipulate commit scopes using the following functions: @@ -35,13 +35,29 @@ confirmation_level: [ ON { received|replicated|durable|visible } ] commit_scope_kind: -{ GROUP COMMIT [ ( group_commit_parameter = value [, ...] ) ] [ ABORT ON ( abort_on_parameter = value ) ] - | CAMO [ DEGRADE ON ( degrade_on_parameter = value ) TO ASYNC ] +{ GROUP COMMIT [ ( group_commit_parameter = value [, ... ] ) ] [ ABORT ON ( abort_on_parameter = value ) ] [ DEGRADE ON (degrade_on_parameter = value [, ... ] ) TO commit_scope_degrade_operation ] + | CAMO [ DEGRADE ON ( degrade_on_parameter = value [, ... ] ) TO ASYNC ] | LAG CONTROL [ ( lag_control_parameter = value [, ... ] ) ] - | SYNCHRONOUS_COMMIT } + | SYNCHRONOUS_COMMIT [ DEGRADE ON (degrade_on_parameter = value ) TO commit_scope_degrade_operation ] } + +commit_scope_degrade_operation: + { commit_scope_group confirmation_level commit_scope_kind} + ``` -Where `node_group` is the name of a PGD data node group. +Where `node_group` is the name of a PGD data node group. + +### commit_scope_degrade_operation + +The `commit_scope_degrade_operation` is either the same commit scope kind with a less restrictive commit scope group as the overall rule being defined, or is asynchronous (`ASYNC`). + +For instance, you can degrade from an `ALL SYNCHRONOUS_COMMIT` to a `MAJORITY SYNCHRONOUS_COMMIT` or a `MAJORITY SYNCHRONOUS_COMMIT` to an `ANY 3 SYNCHRONOUS_COMMIT` or even an `ANY 3 SYNCHRONOUS_COMMIT` to an `ANY 2 SYNCHRONOUS_COMMIT`. You can also degrade from `SYNCRHONOUS_COMMIT` to `ASYNC`. However, you cannot degrade from `SYNCHRONOUS_COMMIT` to `GROUP_COMMIT` or the other way around, regardless of the commit scope groups involved. + +It is also possible to combine rules using `AND`, each with their own degradation clause: + +``` +ALL ORIGIN_GROUP SYNCHRONOUS_COMMIT DEGRADE ON (timeout = 10s) TO MAJORITY ORIGIN_GROUP SYNCHRONOUS COMMIT AND ANY 1 NOT ORIGIN_GROUP SYNCHRONOUS_COMMIT DEGRADE ON (timeout = 20s) TO ASYNC +``` ## Commit scope groups @@ -107,22 +123,42 @@ This is the default visibility. A transaction is confirmed after all of its chan More details of the commit scope kinds and details of their parameters: +- [Synchronous Commit](#synchronous_commit) - [Group Commit](#group-commit) - [CAMO (Commit At Most Once)](#camo) - [Lag Control](#lag-control) -- [Synchronous Commit](#synchronous_commit) + !!!Note Parameter values Specify Boolean, enum, int, and interval values using the [Postgres GUC parameter value conventions](https://www.postgresql.org/docs/current/config-setting.html#CONFIG-SETTING-NAMES-VALUES). !!! +## SYNCHRONOUS_COMMIT + +``` +SYNCHRONOUS_COMMIT [ DEGRADE ON (degrade_on_parameter = value ) TO commit_scope_degrade_operation ] +``` + +### DEGRADE ON parameters + +| Parameter | Type | Default | Description | +| ------------------ | -------- | ------- | ------------------------------------------------------------------------------------------------------------ | +| `timeout` | interval | 0 | Timeout in milliseconds (accepts other units) after which operation degrades. (0 means not set.) | +| `require_write_lead` | Boolean | False | Specifies whether the node must be a write lead to be able to switch to degraded operation. | + +These set the conditions on which the commit scope rule will degrade to a less restrictive mode of operation. + +### commit_scope_degrade_operation + +The `commit_scope_degrade_operation` must be `SYNCHRONOUS_COMMIT` with a less restrictive commit scope group—or must be asynchronous (`ASYNC`). + ## GROUP COMMIT -Allows commits to be confirmed by a consensus of nodes and controls conflict resolution settings. +Allows commits to be confirmed by a consensus of nodes, controls conflict resolution settings, and, like [`SYNCHRONOUS_COMMIT`](#synchronous_commit), has optional rule-degredation parameters. ``` -GROUP COMMIT [ ( group_commit_parameter = value [, ...] ) ] [ ABORT ON ( abort_on_parameter = value ) ] +GROUP COMMIT [ ( group_commit_parameter = value [, ...] ) ] [ ABORT ON ( abort_on_parameter = value ) ] [ DEGRADE ON (degrade_on_parameter = value ) TO commit_scope_degrade_operation ] ``` ### GROUP COMMIT parameters @@ -138,7 +174,14 @@ GROUP COMMIT [ ( group_commit_parameter = value [, ...] ) ] [ ABORT ON ( abort_o | Parameter | Type | Default | Description | | -------------------- | -------- | ------- | ----------------------------------------------------------------------------------------------------------- | | `timeout` | interval | 0 | Timeout in milliseconds (accepts other units). (0 means not set.) | -| `require_write_lead` | bool | false | CAMO only. If set, then for a transaction to switch to local (async) mode, a consensus request is required. | +| `require_write_lead` | Boolean | False | CAMO only. If set, then for a transaction to switch to local (async) mode, a consensus request is required. | + +### DEGRADE ON parameters + +| Parameter | Type | Default | Description | +| ------------------ | -------- | ------- | ------------------------------------------------------------------------------------------------------------ | +| `timeout` | interval | 0 | Timeout in milliseconds (accepts other units) after which operation degrades. (0 means not set.) | +| `require_write_lead` | Boolean | False | Specifies whether the node must be a write lead to be able to switch to degraded operation. | ### transaction_tracking settings @@ -171,6 +214,11 @@ This option must be used when the `ALL` commit scope group is being used to ensu See ["Commit decisions" in Group Commit](../commit-scopes/group-commit/#commit-decisions). +### commit_scope_degrade_operation settings + +The `commit_scope_degrade_operation` must be `GROUP_COMMIT` with a less restrictive commit scope group—or must be asynchronous (`ASYNC`). + + ## CAMO With the client's cooperation, enables protection to prevent multiple insertions of the same transaction in failover scenarios. @@ -181,14 +229,14 @@ See ["CAMO" in Durability](../commit-scopes/camo) for more details. CAMO [ DEGRADE ON ( degrade_on_parameter = value ) TO ASYNC ] ``` -### Degrade On parameters +### DEGRADE ON parameters Allows degrading to asynchronous operation on timeout. | Parameter | Type | Default | Description | | ------------------ | -------- | ------- | ------------------------------------------------------------------------------------------------------------ | -| timeout | interval | 0 | Timeout in milliseconds (accepts other units) after which operation becomes asynchronous. (0 means not set.) | -| require_write_lead | Boolean | False | Specifies whether the node must be a write lead to be able to switch to asynchronous mode. | +| `timeout` | interval | 0 | Timeout in milliseconds (accepts other units) after which operation becomes asynchronous. (0 means not set.) | +| `require_write_lead` | Boolean | False | Specifies whether the node must be a write lead to be able to switch to asynchronous mode. | ## LAG CONTROL @@ -239,10 +287,3 @@ Where: - `diff_secs` is the delta in seconds from the last time the apply rate was calculated. -## SYNCHRONOUS_COMMIT - -``` -SYNCHRONOUS_COMMIT -``` - -The `SYNCHRONOUS_COMMIT` commit scope kind has no parameters. It's effectively configured only by the commit scope group and commit scope visibility. diff --git a/product_docs/docs/pgd/5.6/reference/index.mdx b/product_docs/docs/pgd/5.6/reference/index.mdx index 6d15e13ef5a..fd07ee180ce 100644 --- a/product_docs/docs/pgd/5.6/reference/index.mdx +++ b/product_docs/docs/pgd/5.6/reference/index.mdx @@ -275,6 +275,7 @@ The reference section is a definitive listing of all functions, views, and comma ## [Commit scopes](commit-scopes) * [Commit scope syntax](commit-scopes#commit-scope-syntax) + * [commit_scope_degrade_operation](commit-scopes#commit_scope_degrade_operation) * [Commit scope groups](commit-scopes#commit-scope-groups) * [ANY](commit-scopes#any) * [ANY NOT](commit-scopes#any-not) @@ -288,17 +289,21 @@ The reference section is a definitive listing of all functions, views, and comma * [ON durable](commit-scopes#on-durable) * [ON visible](commit-scopes#on-visible) * [Commit Scope kinds](commit-scopes#commit-scope-kinds) + * [SYNCHRONOUS_COMMIT](commit-scopes#synchronous_commit) + * [DEGRADE ON parameters](commit-scopes#degrade-on-parameters) + * [commit_scope_degrade_operation](commit-scopes#commit_scope_degrade_operation) * [GROUP COMMIT](commit-scopes#group-commit) * [GROUP COMMIT parameters](commit-scopes#group-commit-parameters) * [ABORT ON parameters](commit-scopes#abort-on-parameters) + * [DEGRADE ON parameters](commit-scopes#degrade-on-parameters) * [transaction_tracking settings](commit-scopes#transaction_tracking-settings) * [conflict_resolution settings](commit-scopes#conflict_resolution-settings) * [commit_decision settings](commit-scopes#commit_decision-settings) + * [commit_scope_degrade_operation settings](commit-scopes#commit_scope_degrade_operation-settings) * [CAMO](commit-scopes#camo) - * [Degrade On parameters](commit-scopes#degrade-on-parameters) + * [DEGRADE ON parameters](commit-scopes#degrade-on-parameters) * [LAG CONTROL](commit-scopes#lag-control) * [LAG CONTROL parameters](commit-scopes#lag-control-parameters) - * [SYNCHRONOUS_COMMIT](commit-scopes#synchronous_commit) ## [Conflicts](conflicts) diff --git a/src/components/code-block.js b/src/components/code-block.js index 9b2671b9cf9..0a901c982bb 100644 --- a/src/components/code-block.js +++ b/src/components/code-block.js @@ -1,5 +1,7 @@ import React, { useState } from "react"; import { Button } from "react-bootstrap"; +import { Tooltip } from "react-bootstrap"; +import { OverlayTrigger } from "react-bootstrap"; const childToString = (child) => { if (typeof child === "string") { @@ -57,8 +59,14 @@ const splitChildrenIntoCodeAndOutput = (rawChildren) => { return [code, output]; }; -const CodePre = ({ className, content, runnable }) => { +const unwrappedstring = "→ Wrap"; +const wrappedstring = "↩ Unwrap"; + +const CodePre = ({ className, content, runnable, startWrapped }) => { const codeRef = React.createRef(); + const [wrapButtonText, setWrapButtonText] = useState( + !startWrapped ? unwrappedstring : wrappedstring, + ); const [copyButtonText, setCopyButtonText] = useState("Copy"); const copyClick = (e) => { const text = codeRef.current && codeRef.current.textContent; @@ -71,9 +79,15 @@ const CodePre = ({ className, content, runnable }) => { e.target.blur(); }; - const [wrap, setWrap] = useState(false); + const [wrap, setWrap] = useState(startWrapped); + const wrapClick = (e) => { setWrap(!wrap); + if (!wrap) { + setWrapButtonText(wrappedstring); + } else { + setWrapButtonText(unwrappedstring); + } e.target.blur(); }; @@ -92,9 +106,15 @@ const CodePre = ({ className, content, runnable }) => { <>
- + Toggle wrapping} + placement="bottom" + > + + @@ -136,6 +156,9 @@ const CodeBlock = ({ children, codeLanguages, ...otherProps }) => { const [codeContent, outputContent] = childIsComponent ? splitChildrenIntoCodeAndOutput(children.props.children) : [children, ""]; + + const startWrapped = false; + const language = childIsComponent ? (children.props.className || "").replace("language-", "") : "text"; @@ -151,6 +174,7 @@ const CodeBlock = ({ children, codeLanguages, ...otherProps }) => { className={`language-${language}`} content={codeContent} runnable={execLanguages.includes(language)} + startWrapped={startWrapped} /> {outputContent.length > 0 && }