Hi Vignesh, I agree with Peter's comment that the changes to FilterRemoteOriginData() should be part of FilterByOrigin()
Further, I wonder why "onlylocal_data" is a replication slot's property. A replication slot tracks the progress of replication and it may be used by different receivers with different options. I could start one receiver which wants only local data, say using "pg_logical_slot_get_changes" and later start another receiver which fetches all the data starting from where the first receiver left. This option prevents such flexibility. As discussed earlier in the thread, local_only can be property of publication or subscription, depending upon the use case, but I can't see any reason that it should be tied to a replication slot. I have a similar question for "two_phase" but the ship has sailed and probably it makes some sense there which I don't know. As for publication vs subscription, I think both are useful cases. 1. It will be a publication's property, if we want the node to not publish any data that it receives from other nodes for a given set of tables. 2. It will be the subscription's property, if we want the subscription to decide whether it wants to fetch the data changed on only upstream or other nodes as well. Maybe we want to add it to both and use the stricter of both. If a publication has local_only, it publishes only local changes. If the subscription has local only then WAL sender sends only local changes. -- Best Wishes, Ashutosh
