Re: Issue with logical replication slot during switchover

Hi,

On Fri, 31 Oct 2025 at 09:16, Fabrice Chapuis <fabrice636861@gmail.com> wrote:

Hi, 
I indeed proposed a solution at the top of this thread to modify only the value of the synced attribute, but the discussion was redirected to adding an extra parameter to the function pg_create_logical_replication_slot() to overwrite a failover slot

We had discussed this point in another thread, please see [1]. After
discussion it was decided to not go this way.

[1]: https://www.postgresql.org/message-id/OS0PR01MB57161FF469DE049765DD53A89475A%40OS0PR01MB5716.jpnprd01.prod.outlook.com

I’ve read through the referenced discussion, and my impression is that we might be trying to design a solution around assumptions that are unlikely to hold in practice.
There was an argument that at some point we might allow creating logical failover slots on cascading standbys. However, if we consider all practical scenarios, it seems very unlikely that such a feature could work reliably with the current design.
Let me try to explain why.

Consider the following setup:

node1 - primary  
node2 - standby, replicating from node1  
node3 - standby, replicating from node1, has logical slot foo (failover=true, synced=false)  
node4 - standby, replicating from node3, has logical slot foo (failover=true, synced=true)

1) If node1 fails, we could promote either node2 or node3:
1.a) If we promote node2, we must first create a physical slot for node3, update primary_conninfo on node3 to point to node2, wait until node3 connects, and until catalog_xmin on the physical slot becomes non-NULL. Only then would it be safe to promote node2. This introduces unnecessary steps, complexity, and waiting — increasing downtime, which defeats the goal of high availability.
1.b) If we promote node3, promotion itself is fast, but subscribers will still be using the slot on the original primary. This again defeats the purpose of doing logical replication from a standby, and it won’t be possible to switch subscribers to node4 (see below).

2) If node3 fails, we might want to replace it with node4. But node4 has a slot with failover=true and synced=true, and synced=true prevents it from being used for streaming because it’s a standby.

In other words, with the current design, allowing creation of logical failover slots on standbys doesn’t bring any real benefit — such “synced” slots can’t actually be used later.

One could argue that we could add a function to switch synced=true->false on a standby, but that would just add another workaround on top of an already fragile design, increasing operational complexity without solving the underlying issue.

The same applies to proposals like allow_overwrite. If such a flag is introduced, in practice it will almost always be used unconditionally, e.g.:

SELECT pg_create_logical_replication_slot('<name>', '<plugin>', failover := true, allow_overwrite := true);

Right now, logical failover slots can’t be reused after a switchover, which is a perfectly normal operation.
The only current workaround is to detect standbys with failover=true, synced=false and drop those slots, hoping they’ll be resynchronized. But resynchronization is asynchronous, unpredictable, and may take an unbounded amount of time. If the primary fails during that window, there might be no standby with ready logical slots.

Instead of dropping such slots, what we actually need is a way to safely set synced=false->true and continue operating.

Operating logical replication setups is already extremely complex and error-prone — this is not theoretical, it’s something many of us face daily.
So rather than adding more speculative features or workarounds, I think we should focus on addressing real operational pain points and the inconsistencies in the current design.

A slot created on the primary (which later becomes a standby) with failover=true has a very clear purpose. The failover flag already indicates that purpose; synced shouldn’t override it.

Regards,

--

Alexander Kukushkin