Skip to content

Commit ea1b589

Browse files
authored
feat(replication): explain configs for replication retries (#74)
1 parent 82f66d1 commit ea1b589

4 files changed

Lines changed: 43 additions & 0 deletions

File tree

docs/configuration/pgdog.toml/databases.md

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -98,6 +98,13 @@ Overrides the [`min_pool_size`](general.md#min_pool_size) setting. The connectio
9898

9999
This setting configures the `statement_timeout` connection parameter on all connections to Postgres for this database.
100100

101+
102+
### `lock_timeout`
103+
104+
Configures the `lock_timeout` connection parameter on all connections to Postgres for this database. Aborts any statement that waits longer than the specified duration to acquire a lock. Unlike `statement_timeout`, this only counts time spent waiting for locks, not total execution time.
105+
106+
Default: **none** (not set)
107+
101108
### `idle_timeout`
102109

103110
Overrides the [`idle_timeout`](general.md#idle_timeout) setting. Idle server connections exceeding this timeout will be closed automatically.

docs/configuration/pgdog.toml/general.md

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -554,6 +554,18 @@ Base delay, in milliseconds, between table copy retries during resharding. Each
554554

555555
Default: **`1_000`** (1s)
556556

557+
### `resharding_replication_retry_max_attempts`
558+
559+
Maximum number of retries for a transient error during the logical replication streaming phase of resharding. `0` means retry indefinitely.
560+
561+
Default: **`5`**
562+
563+
### `resharding_replication_retry_min_delay`
564+
565+
Fixed delay, in milliseconds, between replication stream retry attempts. Unlike [`resharding_copy_retry_min_delay`](#resharding_copy_retry_min_delay), this value is not subject to exponential backoff; the same delay is applied on every attempt.
566+
567+
Default: **`1_000`** (1s)
568+
557569
### `reload_schema_on_ddl`
558570

559571
!!! warning

docs/configuration/users.toml/users.md

Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -81,6 +81,16 @@ Sets the `statement_timeout` on all server connections at connection creation. T
8181
!!! note
8282
Nothing is preventing the user from manually changing this setting at runtime, e.g., by running `SET statement_timeout TO 0`;
8383

84+
85+
### `lock_timeout`
86+
87+
Sets the `lock_timeout` on all server connections at connection creation. Aborts any statement that waits longer than the specified duration to acquire a lock. Unlike `statement_timeout`, this only counts time spent waiting for locks, not total execution time.
88+
89+
Default: **none** (not set)
90+
91+
!!! note
92+
Nothing is preventing the user from manually changing this setting at runtime, e.g., by running `SET lock_timeout TO 0`;
93+
8494
### `replication_mode`
8595

8696
Sets the `replication=database` parameter on user connections to Postgres. Allows this user to use replication commands.

docs/features/sharding/resharding/move.md

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -234,6 +234,20 @@ resharding_copy_retry_max_attempts = 5 # per-table retry attempts
234234
resharding_copy_retry_min_delay = 1000 # base backoff in ms; doubles each attempt, max 32×
235235
```
236236

237+
### Transient errors during replication streaming
238+
239+
After the initial copy completes, PgDog streams WAL changes from the source. If a transient error occurs (e.g., a dropped connection or a momentary network interruption) during streaming, PgDog retries automatically: it sleeps for the configured delay, then reconnects using the source replication slot and all destination shard connections in parallel before resuming.
240+
241+
By default: up to **5 attempts**, with a fixed **1 second** delay between each.
242+
243+
To change the defaults, configure [`resharding_replication_retry_max_attempts`](../../../configuration/pgdog.toml/general.md#resharding_replication_retry_max_attempts) and [`resharding_replication_retry_min_delay`](../../../configuration/pgdog.toml/general.md#resharding_replication_retry_min_delay) in `pgdog.toml`:
244+
245+
```toml
246+
[general]
247+
resharding_replication_retry_max_attempts = 5 # 0 = retry indefinitely
248+
resharding_replication_retry_min_delay = 1000 # fixed delay in ms
249+
```
250+
237251
### Primary key violations when retrying after copy failure
238252

239253
In rare cases, if the connection drops after `COPY` commits but before PgDog records the table as done, some rows may remain in the destination. The next retry will hit primary key violations.

0 commit comments

Comments
 (0)