On Fri, Jun 13, 2025 at 10:52 PM Perumal Raj <perucinci@gmail.com> wrote: > > Thanks for explanation Shveta! > > ------------ > As Summary in this original thread, > > Prerequisites for Setting Up a Logical Replication Slot sync in >= pg17 > > To successfully configure a logical replication slot, ensure the following settings are applied: > > wal_level = 'logical' > hot_standby = 'on' > hot_standby_feedback = 'on' > sync_replication_slots = 'on' >
Additionally, you need to configure primary_slot_name on the standby and have dbname in primary_conninfo. For further details, you can refer docs (1)(2).
Thanks for the notes here.
Yes, those parameters configured as part of Normal Physical replication setup.
> Replication Slot Synchronization > > Logical replication slots can synchronize with all direct standby servers of the primary but are not compatible with cascade standby servers. > > Temporary Status of New Standby Slots > > If a new standby server is created after the logical replication slot, it will be marked as temporary=true until the reset_lsn of the primary matches the confirmed_lsn of the new standby. >
It is restart_lsn on both nodes, but there are other things like slot's catalog_xmin as well. As a user, you need to ensure that your primary's logical slot is being consumed. And this is required primarily at the initial sync time so that we sync the slot only if the standby has required resources like WAL to allow decoding from the synced slot after failover.
Thanks for correcting,
> Limitations on Using Logical Replication Slots > > While logical replication slots can synchronize on the direct standby side, they cannot be utilized (as in the case of Debezium) until the standby server is promoted to primary. Attempting to use a synchronized logical slot on a standby server will result in the following error: > > org.postgresql.util.PSQLException: ERROR: cannot use replication slot "kafka_logical_slot" for logical decoding > Detail: This replication slot is being synchronized from the primary server. >
I don't think we can call this a limitation. According to me, this is a requirement for this feature to work. Consider if we allow the use of this synced slot for decoding when sync is still in-progress, this slot could be advanced ahead of the primary. Now, after the failover, we won't be able to reuse this slot to allow the subscribers to continue replication.
