Re: adding partitioned tables to publications

On Mon, Nov 11, 2019 at 9:49 PM Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 2019-11-11 08:59, Amit Langote wrote:
> > On Fri, Nov 8, 2019 at 1:27 PM Amit Langote <amitlangote09(at)gmail(dot)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