Re: adding partitioned tables to publications

Sorry about the delay.

On Mon, Nov 4, 2019 at 8:00 PM Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> This patch seems excessively complicated to me.  Why don't you just add
> the actual partitioned table to pg_publication_rel and then expand the
> partition hierarchy in pgoutput (get_rel_sync_entry() or
> GetRelationPublications() or somewhere around there).  Then you don't
> need to do any work in table DDL to keep the list of published tables up
> to date.

I tend to agree that having to manage this at the DDL level would be
bug-prone, not to mention pretty complicated code to implement it.

I have tried to implement it the way you suggested.  So every decoded
change to a leaf partition will now be published not only via its own
publication but also via publications of its ancestors if any.  That
irrespective of whether a row is directly inserted into the leaf
partition or got routed to it via insert done on an ancestor.  In this
implementation, the only pg_publication_rel entry is the one
corresponding to the partitioned table.

On the subscription side, when creating pg_subscription_rel entries,
for a publication containing a partitioned table, all of its
partitions too must be fetched as being included in the publication.
That is necessary, because the initial syncing copy and subsequently
received changes must be applied to individual partitions.  That could
be changed in the future by publishing leaf partition changes as
changes to the actually published partitioned table.  That future
implementation will also hopefully take care of the concern that Rafia
mentioned on this thread that even with this patch, one must make sure
that tables match one-to-one when they're in publish-subscribe
relationship, which actually needs us to bake in low-level details
like table's relkind in the protocol exchanges.

Anyway, I've attached two patches -- 0001 is a refactoring patch. 0002
implements the feature.

Thanks,
Amit