Replication

• 1: hot_standby
• 2: hot_standby_feedback
• 3: idle_replication_slot_timeout
• 4: max_active_replication_origins
• 5: max_logical_replication_workers
• 6: max_parallel_apply_workers_per_subscription
• 7: max_repack_replication_slots
• 8: max_replication_slots
• 9: max_slot_wal_keep_size
• 10: max_standby_archive_delay
• 11: max_standby_streaming_delay
• 12: max_sync_workers_per_subscription
• 13: max_wal_senders
• 14: output_plugin_libraries
• 15: primary_conninfo
• 16: primary_slot_name
• 17: promote_trigger_file
• 18: recovery_min_apply_delay
• 19: replication_timeout
• 20: sync_replication_slots
• 21: synchronized_standby_slots
• 22: synchronous_standby_names
• 23: track_commit_timestamp
• 24: vacuum_defer_cleanup_age
• 25: wal_keep_segments
• 26: wal_keep_size
• 27: wal_receiver_create_temp_slot
• 28: wal_receiver_status_interval
• 29: wal_receiver_timeout
• 30: wal_retrieve_retry_interval
• 31: wal_sender_delay
• 32: wal_sender_shutdown_timeout
• 33: wal_sender_timeout

1 - hot_standby

Identity

Lifecycle

Default history

How it works

Allows connections and queries during recovery. The value is fixed when the server starts, so changing it requires a restart.

When recovery has reached a consistent state, this permits read-only connections and queries. Replay still has priority: WAL records that conflict with snapshots or locks can cancel queries according to the standby-delay settings.

Monitor and change hot_standby together with primary_conninfo, primary_slot_name, restore_command. 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.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

primary_conninfo · primary_slot_name · restore_command · wal_receiver_timeout · wal_retrieve_retry_interval · max_standby_archive_delay

References

• PostgreSQL 19 Beta 3 — hot_standby
• PostgreSQL 19 release notes
• Machine-readable GUC export

2 - hot_standby_feedback

Identity

Lifecycle

Default history

How it works

A standby with feedback enabled reports information about snapshots needed by its running queries to the primary or upstream standby. The upstream can then avoid vacuum cleanup that would remove row versions still visible to those queries. Messages are not sent more frequently than wal_receiver_status_interval.

Avoiding cleanup conflicts transfers the cost to the primary: dead row versions can remain longer, increasing table and index bloat and vacuum work. In cascading replication feedback is passed upstream, so one old snapshot far downstream can affect the primary.

The mechanism addresses cleanup-record conflicts, not every hot-standby conflict. DDL locks, dropped objects, tablespace actions, and some page-level conflicts can still cancel queries. Feedback also has gaps while a non-slot standby is disconnected, and clock changes can disturb its timing.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Enabling it and ignoring table or index bloat on the primary.
• Expecting it to prevent DDL, lock, database-drop, or tablespace conflicts.
• Allowing an unbounded long query on a downstream standby to hold back cleanup upstream.
• Assuming feedback remains effective while a slotless standby is disconnected.
• Ignoring clock jumps and wal_receiver_status_interval when reasoning about feedback timing.

Related parameters

max_standby_streaming_delay · max_standby_archive_delay · wal_receiver_status_interval · primary_slot_name · autovacuum_vacuum_scale_factor · log_recovery_conflict_waits

References

• PostgreSQL 19 Beta 3 — hot_standby_feedback
• PostgreSQL 18: Handling Hot Standby Query Conflicts
• PostgreSQL 18: Replication Slots
• PostgreSQL 19 release notes
• Machine-readable GUC export

3 - idle_replication_slot_timeout

Identity

Lifecycle

Default history

How it works

Sets the duration a replication slot can remain idle before it is invalidated. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

PostgreSQL 18 measures inactivity from pg_replication_slots.inactive_since and invalidates eligible slots at a checkpoint after the timeout. Zero disables the policy; slots that reserve no WAL and synchronized standby slots are outside this mechanism.

Monitor and change idle_replication_slot_timeout together with max_replication_slots, max_slot_wal_keep_size, primary_slot_name. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Expecting invalidation exactly when the duration expires rather than at a later checkpoint.
• Assuming synchronized standby slots are eligible.
• Allowing an automatic invalidation without a subscriber rebootstrap runbook.
• 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.

Related parameters

max_replication_slots · max_slot_wal_keep_size · primary_slot_name · wal_keep_size · checkpoint_timeout · max_wal_senders

References

• PostgreSQL 19 Beta 3 — idle_replication_slot_timeout
• PostgreSQL 19 release notes
• Machine-readable GUC export

4 - max_active_replication_origins

Identity

Lifecycle

Default history

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.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

max_logical_replication_workers · max_replication_slots · track_commit_timestamp · max_parallel_apply_workers_per_subscription · max_sync_workers_per_subscription · hot_standby

References

• PostgreSQL 19 Beta 3 — max_active_replication_origins
• PostgreSQL 19 release notes
• Machine-readable GUC export

5 - max_logical_replication_workers

Identity

Lifecycle

Default history

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.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

max_parallel_apply_workers_per_subscription · max_sync_workers_per_subscription · max_worker_processes · max_replication_slots · max_active_replication_origins · track_commit_timestamp

References

• PostgreSQL 19 Beta 3 — max_logical_replication_workers
• PostgreSQL 19 release notes
• Machine-readable GUC export

6 - max_parallel_apply_workers_per_subscription

Identity

Lifecycle

Default history

How it works

Maximum number of parallel apply workers per subscription. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

A subscription leader can use up to this many parallel workers to apply suitable in-progress transactions. More workers do not parallelize every transaction and consume the global logical-replication and background-worker pools.

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

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

max_logical_replication_workers · max_sync_workers_per_subscription · max_worker_processes · max_replication_slots · max_active_replication_origins · hot_standby

References

• PostgreSQL 19 Beta 3 — max_parallel_apply_workers_per_subscription
• PostgreSQL 19 release notes
• Machine-readable GUC export

7 - max_repack_replication_slots

Identity

Lifecycle

Default history

How it works

PostgreSQL describes max_repack_replication_slots as follows: “Sets the maximum number of replication slots for use by REPACK.” The value is fixed when the server starts, so changing it requires a controlled restart. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

PostgreSQL 19’s REPACK command can use dedicated replication slots to reorganize a relation concurrently while tracking changes. This startup ceiling reserves how many such slots the server can support; it interacts with the overall replication-slot and WAL-sender budgets and with retained-WAL disk risk.

Read it together with max_replication_slots, max_wal_senders, wal_level, max_slot_wal_keep_size. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for max_repack_replication_slots as proof of the effective value on an initialized or managed cluster.
• Applying a change as though it were immediate while pg_settings reports postmaster context.
• Changing this setting in isolation without checking the linked limits, observability, and rollback path.
• Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Related parameters

max_replication_slots · max_wal_senders · wal_level · max_slot_wal_keep_size · wal_sender_shutdown_timeout

References

• PostgreSQL 19 Beta 3 — max_repack_replication_slots
• PostgreSQL 19 release notes
• Machine-readable GUC export

8 - max_replication_slots

Identity

Lifecycle

Default history

How it works

PostgreSQL allocates replication-slot control capacity at server start. Physical slots can reserve WAL for standbys, while logical slots can reserve both WAL and catalog visibility information for decoding consumers.

The setting limits slot objects, not active WAL-sender connections; max_wal_senders is a separate limit. Slot use also requires wal_level = replica or higher. Reducing the setting below the number of existing slots prevents the server from starting.

An unused slot is not harmless merely because it has no active process. A persistent inactive slot can retain WAL, and a logical slot can hold catalog_xmin, so slot inventory and consumer lifecycle are as important as the numerical ceiling.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Confusing the slot limit with max_wal_senders, which limits concurrent sender processes.
• Lowering the value below the current slot count and making PostgreSQL fail to start.
• Assuming inactive slots cannot retain WAL or catalog row versions.
• Raising the ceiling without monitoring restart_lsn, catalog_xmin, and consumer health.
• Creating permanent slots during experiments and never dropping them.

Related parameters

max_wal_senders · max_slot_wal_keep_size · wal_level · idle_replication_slot_timeout · max_logical_replication_workers · primary_slot_name

References

• PostgreSQL 19 Beta 3 — max_replication_slots
• PostgreSQL 18: Replication Slots
• PostgreSQL 18: pg_replication_slots
• PostgreSQL 19 release notes
• Machine-readable GUC export

9 - max_slot_wal_keep_size

Identity

Lifecycle

Default history

How it works

At checkpoint time PostgreSQL compares a slot’s restart_lsn with the current WAL position. With the default -1 there is no parameter-imposed maximum; a stalled consumer can therefore retain enough WAL to fill pg_wal.

With a finite limit, required segments can be released when a slot falls too far behind. The slot can move through unreserved to lost status, and its consumer may need a new base backup or logical resynchronization. The cap protects server storage by sacrificing the guarantee that an indefinitely lagging slot remains usable.

Enforcement is checkpoint-based, so it is neither instantaneous nor an exact byte ceiling. pg_replication_slots exposes restart_lsn, wal_status, invalidation_reason, and safe_wal_size; these are the operational signals needed before the slot reaches the limit.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Leaving -1 and assuming a stalled slot cannot fill the disk.
• Treating the finite value as an instantaneous hard ceiling despite checkpoint-based enforcement.
• Setting it too low and invalidating a healthy consumer during a planned bulk load.
• Assuming a consumer can always resume after its required WAL has been removed.
• Confusing this per-slot retention cap with the wal_keep_size retention floor.

Related parameters

max_replication_slots · wal_keep_size · max_wal_size · idle_replication_slot_timeout · checkpoint_timeout · archive_mode

References

• PostgreSQL 19 Beta 3 — max_slot_wal_keep_size
• PostgreSQL 18: Replication Slots
• PostgreSQL 18: pg_replication_slots
• PostgreSQL 19 release notes
• Machine-readable GUC export

10 - max_standby_archive_delay

Identity

Lifecycle

Default history

How it works

Sets the maximum delay before canceling queries when a hot standby server is processing archived WAL data. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

While replaying WAL fetched from an archive, recovery may wait up to this accumulated delay for conflicting hot-standby queries before canceling them. It is measured against replay progress, not granted afresh to every query; -1 can let replay lag without bound.

Monitor and change max_standby_archive_delay together with max_standby_streaming_delay, hot_standby, hot_standby_feedback. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

max_standby_streaming_delay · hot_standby · hot_standby_feedback · recovery_min_apply_delay · primary_conninfo · primary_slot_name

References

• PostgreSQL 19 Beta 3 — max_standby_archive_delay
• PostgreSQL 19 release notes
• Machine-readable GUC export

11 - max_standby_streaming_delay

Identity

Lifecycle

Default history

How it works

Sets the maximum delay before canceling queries when a hot standby server is processing streamed WAL data. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

While replaying streamed WAL, recovery may wait up to this accumulated delay for conflicting queries before cancellation. Larger values favor read continuity but raise replication lag and recovery-point exposure; hot_standby_feedback addresses some snapshot conflicts with primary-side bloat risk.

Monitor and change max_standby_streaming_delay together with max_standby_archive_delay, hot_standby, hot_standby_feedback. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

max_standby_archive_delay · hot_standby · hot_standby_feedback · recovery_min_apply_delay · in_hot_standby · primary_conninfo

References

• PostgreSQL 19 Beta 3 — max_standby_streaming_delay
• PostgreSQL 19 release notes
• Machine-readable GUC export

12 - max_sync_workers_per_subscription

Identity

Lifecycle

Default history

How it works

Maximum number of table synchronization workers per subscription. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

Initial table copies use synchronization workers up to this per-subscription ceiling. They share max_logical_replication_workers and max_worker_processes with apply workers, so the configured number is not a guaranteed concurrency level.

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

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

max_logical_replication_workers · max_parallel_apply_workers_per_subscription · max_worker_processes · max_replication_slots · max_active_replication_origins · hot_standby

References

• PostgreSQL 19 Beta 3 — max_sync_workers_per_subscription
• PostgreSQL 19 release notes
• Machine-readable GUC export

13 - max_wal_senders

Identity

Lifecycle

Default history

How it works

Sets the maximum number of simultaneously running WAL sender processes. The value is fixed when the server starts, so changing it requires a restart.

Each streaming standby, WAL-streaming base backup, or logical replication connection can occupy a WAL sender. Zero disables sending, disconnected clients may retain a slot until timeout, and a standby must reserve at least as many senders as its primary to accept hot-standby queries safely.

Monitor and change max_wal_senders together with wal_level, max_replication_slots, archive_mode. 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.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

wal_level · max_replication_slots · archive_mode · wal_log_hints · output_plugin_libraries · wal_sender_timeout

References

• PostgreSQL 19 Beta 3 — max_wal_senders
• PostgreSQL 19 release notes
• Machine-readable GUC export

14 - output_plugin_libraries

Identity

Lifecycle

Default history

How it works

Lists libraries that may be named as logical decoding output plugins. A superuser or a role granted SET privilege can change it for the relevant session or configuration scope.

Logical decoding accepts only output-plugin library names on this server-side allowlist, using LOAD-style naming with an exact plugin-name match. Adding a library is a trust decision because plugin code executes inside the server process.

Monitor and change output_plugin_libraries together with wal_level, max_wal_senders, max_replication_slots. Validate on the relevant server role and real workload, then use its superuser context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

wal_level · max_wal_senders · max_replication_slots · archive_mode · wal_log_hints · shared_preload_libraries

References

• PostgreSQL 19 Beta 3 — output_plugin_libraries
• PostgreSQL 19 release notes
• Machine-readable GUC export

15 - primary_conninfo

Identity

Lifecycle

Default history

How it works

Sets the connection string to be used to connect to the sending server. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

The WAL receiver uses this libpq connection string to reach an upstream sender. Reloading a changed nonempty value restarts the receiver; credentials should come from a protected passfile where possible, and slot synchronization additionally requires dbname.

Monitor and change primary_conninfo together with max_wal_senders, max_replication_slots, wal_level. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Embedding a plaintext password in broadly readable configuration or process diagnostics.
• Omitting dbname when slot synchronization needs it.
• Changing upstream identity without coordinating timeline and slot state.
• 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.

Related parameters

max_wal_senders · max_replication_slots · wal_level · wal_sender_timeout · max_slot_wal_keep_size · primary_slot_name

References

• PostgreSQL 19 Beta 3 — primary_conninfo
• PostgreSQL 19 release notes
• Machine-readable GUC export

16 - primary_slot_name

Identity

Lifecycle

Default history

How it works

Sets the name of the replication slot to use on the sending server. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

The receiver names an existing upstream physical slot so the sender retains WAL needed by this standby. It improves continuity across disconnects but transfers disk-retention risk to the primary and must match slot lifecycle during failover.

Monitor and change primary_slot_name together with wal_keep_segments, wal_keep_size, wal_segment_size. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Creating a slot without monitoring restart_lsn and primary disk usage.
• Dropping or reusing the slot during failover without proving consumer position.
• Assuming a slot alone archives or backs up WAL.
• 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.

Related parameters

wal_keep_segments · wal_keep_size · wal_segment_size · max_slot_wal_keep_size · max_wal_size · idle_replication_slot_timeout

References

• PostgreSQL 19 Beta 3 — primary_slot_name
• PostgreSQL 19 release notes
• Machine-readable GUC export

17 - promote_trigger_file

Identity

Lifecycle

Default history

How it works

Specifies a file name whose presence ends recovery in the standby. The parameter still exists in PG15 and is no longer recognized from PG16. PostgreSQL 16 removed the trigger-file mechanism; use pg_ctl promote or pg_promote() through the HA controller.

While present, the startup/recovery configuration watched for this path and promoted when the file appeared. File races, stale files, and shared-storage semantics made orchestration fragile; PostgreSQL 16 removed the setting.

Before upgrading, inspect hot_standby, hot_standby_feedback, max_standby_archive_delay, remove the old name from configuration, ALTER SYSTEM, role/database settings, and automation templates, and verify the replacement before starting PG16 or later.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG15; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Continuing to emit unknown parameter promote_trigger_file on PG16+.
• Deleting only the setting name without migrating dependent application behavior.
• Assuming the historical default equals the replacement mechanism’s default.
• Missing stale entries in ALTER SYSTEM, role/database settings, or automation templates.

Related parameters

hot_standby · hot_standby_feedback · max_standby_archive_delay · max_standby_streaming_delay · primary_conninfo · primary_slot_name

References

• PostgreSQL 15 — promote_trigger_file
• Machine-readable GUC export

18 - recovery_min_apply_delay

Identity

Lifecycle

Default history

How it works

Sets the minimum delay for applying changes during recovery. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

A standby delays replay of each transaction commit until the configured time has elapsed since the primary’s commit timestamp. Network/cascade lag counts toward the delay, clocks matter, and synchronous_commit=remote_apply makes primary commits wait through the intentional delay.

Monitor and change recovery_min_apply_delay together with max_standby_archive_delay, max_standby_streaming_delay, hot_standby. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

max_standby_archive_delay · max_standby_streaming_delay · hot_standby · hot_standby_feedback · primary_conninfo · primary_slot_name

References

• PostgreSQL 19 Beta 3 — recovery_min_apply_delay
• PostgreSQL 19 release notes
• Machine-readable GUC export

19 - replication_timeout

Identity

Lifecycle

Default history

How it works

PostgreSQL describes replication_timeout as follows: “Sets the maximum time to wait for WAL replication.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG9.1–9.2; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

This early streaming-replication timeout let a sender terminate an inactive connection. PostgreSQL 9.3 replaced the name with wal_sender_timeout; receiver-side failure detection is separately controlled by wal_receiver_timeout, so migration must preserve which side of the connection owns the timer.

Read it together with wal_sender_timeout, wal_receiver_timeout, wal_receiver_status_interval, max_wal_senders. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG9.2; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for replication_timeout as proof of the effective value on an initialized or managed cluster.
• Applying a change as though it were immediate while pg_settings reports sighup context.
• Changing this setting in isolation without checking the linked limits, observability, and rollback path.
• Copying the removed name into a modern postgresql.conf instead of migrating to its documented successor.

Related parameters

wal_sender_timeout · wal_receiver_timeout · wal_receiver_status_interval · max_wal_senders

References

• Machine-readable GUC export

20 - sync_replication_slots

Identity

Lifecycle

Default history

How it works

Enables the slotsync worker on a physical standby to copy logical failover-slot state from its primary. A configuration reload applies a new value.

Synchronization requires a physical replication slot between primary and standby (primary_slot_name on the standby), hot_standby_feedback=on, and primary_conninfo containing a valid dbname. The logical source slots must have failover enabled.

Slot state is copied asynchronously. The primary should list the standby’s physical slot in synchronized_standby_slots so subscribers cannot outrun the failover standby, and operators must verify that every required slot is synchronized and ready before promotion.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Enabling it without primary_slot_name and therefore without the mandatory physical slot.
• Leaving hot_standby_feedback off, which prevents safe catalog-row retention for synchronized logical slots.
• Omitting dbname from primary_conninfo.
• Synchronizing ordinary logical slots that were not created with failover enabled and expecting them to appear.
• Promoting before checking that every required slot is synchronized and not behind its subscriber.

Related parameters

primary_slot_name · hot_standby_feedback · primary_conninfo · synchronized_standby_slots · max_replication_slots · max_slot_wal_keep_size

References

• PostgreSQL 19 Beta 3 — sync_replication_slots
• PostgreSQL 19 release notes
• Machine-readable GUC export

21 - synchronized_standby_slots

Identity

Lifecycle

Default history

How it works

Lists streaming replication standby server replication slot names that logical WAL sender processes will wait for. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

Logical senders on the primary wait until every listed physical standby slot has confirmed the relevant WAL before decoding sends changes. This protects failover-slot continuity, but a missing, invalid, or stalled listed slot can stop logical replication and slot-management functions.

Monitor and change synchronized_standby_slots together with sync_replication_slots, primary_slot_name, max_replication_slots. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Listing a missing or invalid slot and blocking logical senders.
• Confusing physical slot names with standby application_name values.
• Failing to enable sync_replication_slots on the corresponding standbys.
• 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.

Related parameters

sync_replication_slots · primary_slot_name · max_replication_slots · max_slot_wal_keep_size · synchronous_standby_names · vacuum_defer_cleanup_age

References

• PostgreSQL 19 Beta 3 — synchronized_standby_slots
• PostgreSQL 19 release notes
• Machine-readable GUC export

22 - synchronous_standby_names

Identity

Lifecycle

Default history

How it works

Number of synchronous standbys and list of names of potential synchronous ones. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

This parses priority FIRST or quorum ANY syntax over standby application_name values. It only defines eligible acknowledgers; synchronous_commit selects what each transaction waits for, and duplicate or wildcard names can make the chosen standby surprising.

Monitor and change synchronous_standby_names together with synchronous_commit, wal_sender_timeout, max_wal_senders. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Assuming the list alone makes every transaction synchronous.
• Using duplicate application_name values and getting nondeterministic priority.
• Choosing ANY/FIRST counts that cannot be satisfied during planned maintenance.
• 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.

Related parameters

synchronous_commit · wal_sender_timeout · max_wal_senders · application_name · synchronized_standby_slots · vacuum_defer_cleanup_age

References

• PostgreSQL 19 Beta 3 — synchronous_standby_names
• PostgreSQL 19 release notes
• Machine-readable GUC export

23 - track_commit_timestamp

Identity

Lifecycle

Default history

How it works

Collects transaction commit time. The value is fixed when the server starts, so changing it requires a restart.

PostgreSQL stores transaction commit timestamps in an auxiliary SLRU so SQL and replication-origin features can query them later. It must be enabled at startup before the history is collected and adds storage/I/O overhead; it cannot reconstruct older timestamps.

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

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

max_active_replication_origins · max_logical_replication_workers · max_replication_slots · idle_replication_slot_timeout · max_slot_wal_keep_size · max_wal_senders

References

• PostgreSQL 19 Beta 3 — track_commit_timestamp
• PostgreSQL 19 release notes
• Machine-readable GUC export

24 - vacuum_defer_cleanup_age

Identity

Lifecycle

Default history

How it works

Number of transactions by which VACUUM and HOT cleanup should be deferred, if any. The parameter still exists in PG15 and is no longer recognized from PG16. PostgreSQL 16 removed this transaction-count delay; use hot_standby_feedback, replication slots, and bounded standby-conflict policy according to the actual requirement.

This postponed removal of recently dead tuples by a fixed number of transactions on the primary, an imprecise way to protect standby queries. It could retain bloat without guaranteeing a wall-clock delay and was removed in PostgreSQL 16.

Before upgrading, inspect synchronized_standby_slots, synchronous_standby_names, hot_standby, remove the old name from configuration, ALTER SYSTEM, role/database settings, and automation templates, and verify the replacement before starting PG16 or later.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG15; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Continuing to emit unknown parameter vacuum_defer_cleanup_age on PG16+.
• Deleting only the setting name without migrating dependent application behavior.
• Assuming the historical default equals the replacement mechanism’s default.
• Missing stale entries in ALTER SYSTEM, role/database settings, or automation templates.

Related parameters

synchronized_standby_slots · synchronous_standby_names · hot_standby · hot_standby_feedback · idle_replication_slot_timeout · max_active_replication_origins

References

• PostgreSQL 15 — vacuum_defer_cleanup_age
• Machine-readable GUC export

25 - wal_keep_segments

Identity

Lifecycle

Default history

How it works

Sets the number of WAL files held for standby servers. The parameter still exists in PG12 and is no longer recognized from PG13. PostgreSQL 13 replaced the segment-count interface with wal_keep_size, which expresses the retention floor in bytes rather than assuming a segment size.

This retained at least a count of old WAL segments for lagging standbys, so its byte effect changed with wal_segment_size. It was only a floor—not protection from every retention/removal condition—and PostgreSQL 13 replaced it with wal_keep_size.

Before upgrading, inspect wal_keep_size, wal_segment_size, max_slot_wal_keep_size, remove the old name from configuration, ALTER SYSTEM, role/database settings, and automation templates, and verify the replacement before starting PG13 or later.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG12; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Copying the old integer directly to wal_keep_size without multiplying by wal_segment_size.
• Treating the retained count as a maximum rather than a minimum floor.
• Leaving the removed name in PG13+ automation.
• Continuing to emit unknown parameter wal_keep_segments on PG13+.
• Deleting only the setting name without migrating dependent application behavior.

Related parameters

wal_keep_size · wal_segment_size · max_slot_wal_keep_size · max_wal_size · primary_slot_name · idle_replication_slot_timeout

References

• PostgreSQL 12 — wal_keep_segments
• Machine-readable GUC export

26 - wal_keep_size

Identity

Lifecycle

Default history

How it works

The sender keeps at least wal_keep_size megabytes of past WAL in pg_wal so a lagging standby can continue streaming without an older segment disappearing. If the standby falls behind beyond the available files, streaming disconnects; an archive can supply the missing segment if one exists.

This is a retention floor, not an exact reservation or a maximum. Checkpoint recovery needs, archiving, replication slots, and recent WAL-usage estimates can retain more. A value of zero means PostgreSQL reserves no extra WAL specifically for standbys, not that pg_wal contains no old WAL.

Replication slots retain WAL according to an individual consumer’s confirmed position and are usually more precise. wal_keep_size is still useful as simple insurance for slotless or temporarily reconnecting standbys, but capacity should be based on peak WAL rate multiplied by the intended outage window.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating wal_keep_size as a maximum for pg_wal usage.
• Reading 0 as ‘retain no WAL’ rather than ‘retain no extra WAL for standby purposes’.
• Sizing from average WAL rate and failing during batch-generated peaks.
• Assuming it guarantees recovery after a standby exceeds the retained window.
• Forgetting the predecessor parameter wal_keep_segments when comparing PG12 and PG13.

Related parameters

wal_keep_segments · max_replication_slots · max_slot_wal_keep_size · archive_mode · max_wal_size · primary_slot_name

References

• PostgreSQL 19 Beta 3 — wal_keep_size
• PostgreSQL 18: Replication Slots
• PostgreSQL 18: WAL Configuration
• PostgreSQL 19 release notes
• Machine-readable GUC export

27 - wal_receiver_create_temp_slot

Identity

Lifecycle

Default history

How it works

Sets whether a WAL receiver should create a temporary replication slot if no permanent slot is configured. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

If primary_slot_name is empty, the receiver can create a temporary upstream slot for the lifetime of its connection. That prevents removal during the connection but vanishes on disconnect, so it cannot guarantee catch-up across an outage.

Monitor and change wal_receiver_create_temp_slot together with primary_slot_name, max_replication_slots, max_slot_wal_keep_size. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

primary_slot_name · max_replication_slots · max_slot_wal_keep_size · wal_keep_size · hot_standby · hot_standby_feedback

References

• PostgreSQL 19 Beta 3 — wal_receiver_create_temp_slot
• PostgreSQL 19 release notes
• Machine-readable GUC export

28 - wal_receiver_status_interval

Identity

Lifecycle

Default history

How it works

Sets the maximum interval between WAL receiver status reports to the sending server. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

The receiver sends write, flush, and replay positions upstream at most this far apart, with additional replies when requested. Lower values improve monitoring and feedback freshness but do not make WAL replay itself faster.

Monitor and change wal_receiver_status_interval together with wal_receiver_timeout, wal_sender_timeout, primary_conninfo. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

wal_receiver_timeout · wal_sender_timeout · primary_conninfo · hot_standby_feedback · hot_standby · max_standby_archive_delay

References

• PostgreSQL 19 Beta 3 — wal_receiver_status_interval
• PostgreSQL 19 release notes
• Machine-readable GUC export

29 - wal_receiver_timeout

Identity

Lifecycle

Default history

How it works

Sets the maximum wait time to receive data from the sending server. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

A standby terminates its receiver after this period without sender data, then reconnects according to recovery behavior. It is failure detection, not an end-to-end failover deadline, and must tolerate expected network pauses.

Monitor and change wal_receiver_timeout together with primary_conninfo, primary_slot_name, restore_command. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

primary_conninfo · primary_slot_name · restore_command · wal_retrieve_retry_interval · hot_standby · wal_receiver_status_interval

References

• PostgreSQL 19 Beta 3 — wal_receiver_timeout
• PostgreSQL 19 release notes
• Machine-readable GUC export

30 - wal_retrieve_retry_interval

Identity

Lifecycle

Default history

How it works

Sets the time to wait before retrying to retrieve WAL after a failed attempt. A configuration reload applies a new value; existing work already in flight is not retroactively changed.

After archive, local pg_wal, and streaming retrieval fail, recovery waits this long before another attempt. Small values reduce recovery/standby reaction time but can hammer a missing archive or noisy network with retries.

Monitor and change wal_retrieve_retry_interval together with primary_conninfo, primary_slot_name, restore_command. Validate on the relevant server role and real workload, then use its sighup context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

primary_conninfo · primary_slot_name · restore_command · wal_receiver_timeout · hot_standby · hot_standby_feedback

References

• PostgreSQL 19 Beta 3 — wal_retrieve_retry_interval
• PostgreSQL 19 release notes
• Machine-readable GUC export

31 - wal_sender_delay

Identity

Lifecycle

Default history

How it works

PostgreSQL describes wal_sender_delay as follows: “WAL sender sleep time between WAL replications.” A configuration reload applies the value to the server without a full restart. The atlas measures it in PG9.0–9.1; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

Early WAL senders slept for this interval between attempts to ship more WAL. It disappeared after PostgreSQL 9.1 as sender wakeup and streaming behavior evolved; modern latency and liveness controls are wal_sender_timeout, wal_receiver_status_interval, and wal_receiver_timeout, not a polling delay.

Read it together with wal_sender_timeout, wal_receiver_status_interval, wal_receiver_timeout, max_wal_senders. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG9.1; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for wal_sender_delay as proof of the effective value on an initialized or managed cluster.
• Applying a change as though it were immediate while pg_settings reports sighup context.
• Changing this setting in isolation without checking the linked limits, observability, and rollback path.
• Copying the removed name into a modern postgresql.conf instead of migrating to its documented successor.

Related parameters

wal_sender_timeout · wal_receiver_status_interval · wal_receiver_timeout · max_wal_senders

References

• PostgreSQL 9.1 — wal_sender_delay
• Machine-readable GUC export

32 - wal_sender_shutdown_timeout

Identity

Lifecycle

Default history

How it works

PostgreSQL describes wal_sender_shutdown_timeout as follows: “Sets the maximum time the server waits during shutdown for all WAL data to be replicated to the receiver.” It can be changed per session, which makes plan or behavior comparisons possible without changing every workload. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

During shutdown a sender normally waits until outstanding WAL reaches its receiver. The default -1 waits without a timeout, zero stops immediately, and a positive interval bounds the wait at the cost of possible sender/receiver divergence; connection options can set different policies for physical and logical replication links.

Read it together with wal_sender_timeout, wal_receiver_timeout, synchronous_commit, synchronous_standby_names. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• Treating the measured boot_val for wal_sender_shutdown_timeout as proof of the effective value on an initialized or managed cluster.
• Applying a change as though it were immediate while pg_settings reports user context.
• Changing this setting in isolation without checking the linked limits, observability, and rollback path.
• Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Related parameters

wal_sender_timeout · wal_receiver_timeout · synchronous_commit · synchronous_standby_names · max_wal_senders

References

• PostgreSQL 19 Beta 3 — wal_sender_shutdown_timeout
• PostgreSQL 19 release notes
• Machine-readable GUC export

33 - wal_sender_timeout

Identity

Lifecycle

Default history

How it works

Sets the maximum time to wait for WAL replication. It can be changed at session scope, so different sessions may observe different behavior.

A WAL sender terminates a replication connection that remains inactive for this interval. Each sender session may use a location-appropriate value; zero disables detection and very short settings cause churn across high-latency links.

Monitor and change wal_sender_timeout together with max_wal_senders, max_replication_slots, wal_level. Validate on the relevant server role and real workload, then use its user context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Tuning advice

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Common pitfalls

• 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.

Related parameters

max_wal_senders · max_replication_slots · wal_level · primary_conninfo · max_slot_wal_keep_size · wal_receiver_status_interval

References

• PostgreSQL 19 Beta 3 — wal_sender_timeout
• PostgreSQL 19 release notes
• Machine-readable GUC export