feat(replication): explain configs for replication retries

docs/configuration/pgdog.toml/databases.md

@@ -98,6 +98,13 @@ Overrides the [`min_pool_size`](general.md#min_pool_size) setting. The connectio
 
 This setting configures the `statement_timeout` connection parameter on all connections to Postgres for this database.
 
+
+### `lock_timeout`
+
+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.
+
+Default: **none** (not set)
+
 ### `idle_timeout`
 
 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

@@ -555,6 +555,18 @@ Base delay, in milliseconds, between table copy retries during resharding. Each
 
 Default: **`1_000`** (1s)
 
+### `resharding_replication_retry_max_attempts`
+
+Maximum number of retries for a transient error during the logical replication streaming phase of resharding. `0` means retry indefinitely.
+
+Default: **`5`**
+
+### `resharding_replication_retry_min_delay`
+
+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.
+
+Default: **`1_000`** (1s)
+
 ### `reload_schema_on_ddl`
 
 !!! warning

docs/configuration/users.toml/users.md

@@ -81,6 +81,16 @@ Sets the `statement_timeout` on all server connections at connection creation. T
 !!! note
     Nothing is preventing the user from manually changing this setting at runtime, e.g., by running `SET statement_timeout TO 0`;
 
+
+### `lock_timeout`
+
+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.
+
+Default: **none** (not set)
+
+!!! note
+    Nothing is preventing the user from manually changing this setting at runtime, e.g., by running `SET lock_timeout TO 0`;
+
 ### `replication_mode`
 
 Sets the `replication=database` parameter on user connections to Postgres. Allows this user to use replication commands.

docs/features/sharding/resharding/move.md

@@ -234,6 +234,20 @@ resharding_copy_retry_max_attempts = 5    # per-table retry attempts
 resharding_copy_retry_min_delay = 1000   # base backoff in ms; doubles each attempt, max 32×
 ```
 
+### Transient errors during replication streaming
+
+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.
+
+By default: up to **5 attempts**, with a fixed **1 second** delay between each.
+
+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`:
+
+```toml
+[general]
+resharding_replication_retry_max_attempts = 5    # 0 = retry indefinitely
+resharding_replication_retry_min_delay = 1000   # fixed delay in ms
+```
+
 ### Primary key violations when retrying after copy failure
 
 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.