On Mon, Nov 11, 2019 at 9:49 PM Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 2019-11-11 08:59, Amit Langote wrote: > > On Fri, Nov 8, 2019 at 1:27 PM Amit Langote <amitlangot...@gmail.com> wrote: > >> Anyway, I've attached two patches -- 0001 is a refactoring patch. 0002 > >> implements the feature. > > > > 0002 didn't contain necessary pg_dump changes, which fixed in the > > attached new version. > > That looks more pleasant.
Thanks for looking. > I don't understand why you go through great lengths to ensure that the > relkinds match between publisher and subscriber. We already ensure that > only regular tables are published and only regular tables are allowed as > subscription target. In the future, we may want to allow further > combinations. What situation are you trying to address here? I'd really want to see the requirement for relkinds to have to match go away, but as you can see, this patch doesn't modify enough of pgoutput.c and worker.c to make that possible. Both the code for the initital syncing and that for the subsequent real-time replication assume that both source and target are regular tables. So even if partitioned tables can now be in a publication, they're never sent in the protocol messages, only their leaf partitions are. Initial syncing code can be easily modified to support any combination of source and target relations, but changes needed for real-time replication seem non-trivial. Do you think we should do that before we can say partitioned tables support logical replication? Thanks, Amit