On Fri, Dec 15, 2023 at 5:55 PM Nisha Moond <nisha.moond...@gmail.com> wrote: > > (1) > When we try to create a subscription on standby using a synced slot > that is in 'r' sync_state, the subscription will be created at the > subscriber, and on standby, two actions will take place - > (i) As copy_data is true by default, it will switch the failover > state of the synced-slot to 'false'. > (ii) As we don't allow to use synced-slots, it will start giving > the expected error in the log file - > ERROR: cannot use replication slot "logical_slot" for logical > decoding > DETAIL: This slot is being synced from the primary server. > HINT: Specify another replication slot. > > The first one seems an issue, it toggles the failover to false and > then it remains false after that. I think it should be fixed. >
+1. If we don't allow the slot to be used, we shouldn't allow its state to be changed as well. > (2) > With the patch, the 'CREATE SUBSCRIPTION' command with a 'slot_name' > of an 'active' logical slot fails and errors out - > ERROR: could not alter replication slot "logical_slot" on > publisher: ERROR: replication slot "logical_slot1" is active for PID > xxxx > > Without the patch, the create subscription with an 'active' slot_name > succeeds and the log file shows the error "could not start WAL > streaming: ERROR: replication slot "logical_slot" is active for PID > xxxx". > > Given that the specified active slot_name has failover set to false > and the create subscription command also specifies failover=false, the > expected behavior of the "with-patch" case is anticipated to be the > same as that of the "without-patch" scenario. > Currently, we first acquire the slot to change its state but I guess if we want the behavior as you mentioned we first need to check the slot's 'failover' state without acquiring the slot. I am not sure if that is any better because anyway we are going to fail in the very next step as the slot is busy. -- With Regards, Amit Kapila.