max_active_replication_origins

Definition PG 18 manual

Specifies how many replication origins (see Chapter 48) can be tracked simultaneously, effectively limiting how many logical replication subscriptions can be created on the server. Setting it to a lower value than the current number of tracked replication origins (reflected in pg_replication_origin_status) will prevent the server from starting. It defaults to 10. This parameter can only be set at server start. max_active_replication_origins must be set to at least the number of subscriptions that will be added to the subscriber, plus some reserve for table synchronization.

How it works

Sets the maximum number of active replication origins. The value is fixed when the server starts, so changing it requires a restart.

Each active logical replication origin tracks remote progress so apply can avoid replaying changes twice. The startup allocation effectively bounds concurrently active subscriptions/origins and consumes shared resources even though dormant catalog rows need not all be active.

Monitor and change max_active_replication_origins together with max_logical_replication_workers, max_replication_slots, track_commit_timestamp. 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_active_replication_origins 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.