select open change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

CONFIGURATION / REPLICATION

max_logical_replication_workers

Read PG 18 manual ↗

Specifies maximum number of logical replication workers.

Type
integer
Context
postmaster
Measured default
4
Unit
Metadata snapshot
18

Definition PG 18 manual

Specifies maximum number of logical replication workers. This includes leader apply workers, parallel apply workers, and table synchronization workers.

Logical replication workers are taken from the pool defined by max_worker_processes.

The default value is 4. This parameter can only be set at server start.

Measured default history
Version intervalDefault
10 – 194
Analysis & operational context

Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗

How it works

Maximum number of logical replication worker processes. The value is fixed when the server starts, so changing it requires a restart.

This reserves the logical-replication portion of the background-worker budget for apply, table synchronization, and related workers. The effective capacity is also bounded by max_worker_processes and by the per-subscription worker limits.

Monitor and change max_logical_replication_workers together with max_parallel_apply_workers_per_subscription, max_sync_workers_per_subscription, max_worker_processes. Validate on the relevant server role and real workload, then use its postmaster context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Changing it on the wrong primary, standby, sender, or subscriber role.

Watching only configured bytes/time instead of actual lag, slot position, and worker state.

Failing over to a node that lacks the old primary's capacity or prerequisites.

Using infinite waits or WAL retention to hide a failed consumer.

Workload guidance

OLAP: Read standbys and logical subscribers often see long queries or large transactions. Put explicit bounds on replay/apply and monitor lag, worker saturation, slot restart_lsn, and conflict cancellations.

OLTP: Size max_logical_replication_workers from topology, failover roles, slot/subscription count, and reconnect headroom. Test worst-case primary latency, standby replay, and disk retention before production.

SMALL: Configure only replication capacity that is actually used. Even a small topology needs bounded timeouts and slot lifecycle; unlimited retention is not reliability.

Version history 3
  1. PG 18 → 19changed
  2. PG 15 → 16changed
  3. PG 9.6 → 10added

Related entries

Further reading

Definition snapshot: english-manuals:c7f136b248559d0ac73246253dd… · English manual source