On Wed, Nov 19, 2025 at 6:26 AM Masahiko Sawada <[email protected]> wrote: > > On Tue, Nov 18, 2025 at 1:30 AM Amit Kapila <[email protected]> wrote: > > > > On Sat, Nov 15, 2025 at 4:02 AM Masahiko Sawada <[email protected]> > > wrote: > > > > > > On Fri, Nov 14, 2025 at 2:39 AM Amit Kapila <[email protected]> > > > wrote: > > > > > > > > > > > > The point is quite fundamental, do you think we can sync to a > > > > pre-existing slot with the same name and failover marked as true after > > > > the first time the node joins a new primary? > > > > > > Given the current behavior that we cannot create a logical slot with > > > failover=true on the standby, it makes sense to me that we overwrite > > > the pre-existing slot (with synced=false and failover=true) on the old > > > primary by the slot (with synced=true and failover=true) on the new > > > primary if their names, plugin and other properties matches and the > > > pre-existing slot has lesser LSNs and XIDs than the one on the new > > > primary. But at the same time, we need to consider the possible future > > > changes that allow users to create a slot with failover=true also on > > > the standby. > > > > > > Alexander pointed out[1] that allowing to create a slot with > > > failover=true on the standby won't work with the current > > > implementation. I agree with his analysis, and I guess we would need > > > more changes than simply allowing it, regardless of accepting the > > > proposed change. We might need to introduce a replication slot origin > > > or a generation. > > > > > > > AFAICS, the email you pointed out wrote about use cases, not the > > actual code implementation. We can discuss use cases if we want to > > pursue that implementation, but the reason why we decided not to allow > > it was for the cases where users try to configure cascaded standbys to > > also try to sync slots from the first standby that are already being > > synced from the primary. There are quite a few technical challenges in > > supporting that, like how to make sure primary waits even for cascaded > > standbys before sending the changes to logical subscribers. > > Right. My point is that these are two independent issues. The fact > that creating a slot with failover=true directly on a standby is > difficult (due to the cascaded-standby cases you mentioned) does not, > by itself, justify allowing us to overwrite an existing slot with > failover=true and synced=false during slot synchronization. > > > OTOH, for the cases where there is a totally different logical slot on > > standby (not present on primary) with failover=true, we can allow it > > to be synced from standby-1 to a cascaded standby, though we need some > > way to distinguish those cases. For example, during sync on cascaded > > standby, we can ensure that the slot being synced is not a sync-slot > > (failover=true and sync=true). > > Yes. We need some way to distinguish those slots, otherwise if users > create a slot with the same name on the primary, the slot on standby-1 > (a cascading standby) could be overwritten. I think we would need some > additional metadata per slot to support that safely. >
It shouldn't be overwritten as of current HEAD because we give ERROR if such a slot exists on standby but if we allow overwriting it as being discussed here then we would require additional metadata per slot to distinguish this case. -- With Regards, Amit Kapila.
