On Fri, Jun 16, 2023 at 9:24 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > Is there an alternative implementation I'm missing, maybe, or a way to
> > make this feature more generally applicable? "We have table Y and want
> > it to be migrated as part of table X" seems to fall squarely under the
> > logical replication umbrella.
>
> Are you talking about this w.r.t inheritance/partition hierarchy? I
> don't see any other way except "publish_via_partition_root" because we
> expect the same schema and relation name on the subscriber to
> replicate. You haven't explained why exactly you have such a
> requirement of replicating via inheritance root aka why you want
> inheritance hierarchy to be different on target db.
I think all the "standard" use cases for publish_via_partition_root
still apply to our hypertables, and then add on the fact that our
partitions are dynamically created as needed. The subscriber may have
different ideas on how to divide and size those partitions based on
the extension version. (I'm still trying to figure out how to make
sure those new partitions are automatically included in the
publication, for what it's worth.)
> The other idea that came across my mind was to provide some schema
> mapping kind of feature on subscribers where we could route the tuples
> from table X to table Y provided they have the same or compatible
> schema. I don't know if this is feasible or how generally it will be
> useful and whether any other DB (replication solution) provides such a
> feature but I guess something like that would have helped your use
> case.
Yes, that may have also worked. Making it a subscriber-side feature
requires tight coupling between the two peers, though. (For the
timescaledb case, how does the subscriber know which new partitions
belong to which root? The publisher knows already.) And if it's
publisher-side instead, it would still need something like the
pg_get_publication_rels_to_sync() proposed here.
Thanks,
--Jacob