Replication / Primary Server

synchronized_standby_slots

• What it does: Specifies a list of logical replication slot names that logical WAL sender processes will wait for before sending decoded changes to output plugins.
• Why it matters: This parameter is crucial for logical replication scenarios where you need to ensure that logical decoding and downstream consumers don't get ahead of physical replicas. It provides a synchronization mechanism between logical and physical replication, preventing situations where logical subscribers might see data that isn't yet durable on synchronous physical standbys. This is particularly important for maintaining data consistency across different types of replication consumers and ensuring that logical decoding doesn't create availability issues for synchronous physical replication.
• Ideal value & Best Practice: Set to a comma-separated list of physical replication slot names that should be synchronized with logical decoding. For example: 'standby1,standby2'. Use this when you have both logical replication consumers and synchronous physical standbys, and you need to ensure they remain coordinated. Ensure the specified replication slots actually exist and are active.

synchronous_standby_names

• What it does: Specifies the number and names of synchronous standby servers that must confirm WAL receipt before the primary can commit transactions.
• Why it matters: This is a critical parameter for ensuring data durability and consistency in synchronous replication setups. It determines how many standby servers must acknowledge receipt of WAL data before transactions can commit on the primary. Proper configuration balances between data protection and performance - more synchronous standbys increase durability but may impact write performance. This parameter also supports complex quorum-based synchronization for advanced high-availability scenarios.
• Ideal value & Best Practice: Use the format NUM_SYNC (standby_name1, standby_name2, ...) where NUM_SYNC is the number of synchronous standbys required. For example: 2 (standby1, standby2, standby3) requires any 2 of the 3 listed standbys. For maximum availability with performance, start with 1 (standby1) and increase as needed. Monitor replication latency and adjust based on your durability requirements versus performance tolerance. Always ensure you have enough actual standbys to meet your synchronous requirements.

---

Try pghealth Free Today 🚀

Start your journey toward a healthier PostgreSQL with pghealth.
You can explore all features immediately with a free trial — no installation required.

👉 Start Free Trial