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
