Azure Database for PostgreSQL: Logical Replication Slot Synchronization Issue After HA Deployment

Hi Maraiah,

Thank you, that helps clarify the PostgreSQL 16 requirements. One detail missing from my original question is that we had already added pg_failover_slots to shared_preload_libraries and restarted the server before enabling HA.

I rechecked the Azure server parameters today:

wal_level = LOGICAL
hot_standby_feedback = on
shared_preload_libraries = pg_cron,pg_stat_statements,pg_failover_slots
max_replication_slots = 10
max_wal_senders = 10
metrics.collector_database_activity = ON

None of these parameters shows a pending restart. At our September 28 metric check, the affected slot reported 0throughout the preceding 24 hours.

Is there additional configuration needed for pg_failover_slots, particularly when the logical slot existed before HA was enabled? If these settings are sufficient, what would be the next step to investigate synchronization on the managed standby?

Thanks, Alex

Hello Alex,

Thank you for providing the additional configuration details.

Based on the settings you've shared, the prerequisite configuration appears to be in place:

• wal_level = logical
• hot_standby_feedback = on
• pg_failover_slots loaded through shared_preload_libraries
• metrics.collector_database_activity = ON
• No pending restart required

Since the logical_replication_slot_sync_status metric continues to report 0, this indicates that the logical replication slot has not yet been synchronized to the HA standby. According to the Azure Database for PostgreSQL HA documentation, a value of 0 means logical replication can continue operating on the current primary, but failover readiness for that slot has not been confirmed.

As Azure Database for PostgreSQL Flexible Server is a managed service, the standby server isn't directly accessible for validation. The next recommended step is to collect diagnostic information and investigate whether any slot synchronization errors are being generated internally.

Could you please provide the following information?

SELECT slot_name,

       slot_type,

       plugin,

       active,

       restart_lsn,

       confirmed_flush_lsn

FROM pg_replication_slots;

Also, please confirm:

1. Whether the slot was created with failover support enabled (if applicable to the creation method used).
2. Whether the slot has remained continuously active since HA was enabled.
3. Whether any failover, maintenance event, or HA reconfiguration occurred after the slot was created.

If the metric remains at 0 despite the documented prerequisites being satisfied, we recommend opening a Microsoft Support request so that backend HA synchronization status and service-side logs can be reviewed. These internal synchronization details are not exposed through PostgreSQL system views or customer-accessible diagnostics.

Regards, Maraiah

Hi Maraiah,

Thank you. I ran the query against the production primary; the results are included below.

The ClickPipes logical slot is currently active, with restart_lsn=1B3A/2243AFF8 and confirmed_flush_lsn=1B3A/7D061078. All three physical slots are also active.

Regarding your other questions:

• We’re using PostgreSQL 16 with pg_failover_slots, rather than PostgreSQL 17’s native slot-creation failover option.
• The slot is active now, but we don’t have a continuous activity history to confirm uninterrupted activity since HA was enabled.
• The slot existed before the September 26 restart and HA enablement. HA became Healthy at 04:29 UTC. Our subsequent Azure activity-log review found no later failover or HA reconfiguration.

We already have support case 2609260010000665 open. Could you help coordinate investigation of the managed standby’s logical slot and synchronization logs through that case?

Please coordinate any proposed production changes with us beforehand.

Thanks, Alex