Re: Skipping schema changes in publication

On Wed, Jan 21, 2026 at 11:35 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> Thanks for explaining this, overall I like the Approach 1, and I also
> see the problem when publish via root is given in that case COPY FROM
> is executed on the root and it would be hard to exclude specific
> partitions.  What is the behavior when root of partition tree is added
> but publish via root is not true, it doesn't add any relation to
> publication rel or how does it manage to not copy data from
> partitions?
>

So, I believe you are asking about the behavior of COPY on HEAD for
the following case:

CREATE PUBLICATION pub1 FOR TABLE tab_root WITH
(publish_via_partition_root = false);

In this scenario, pg_publication_rel contains an entry for tab_root,
while pg_publication_tables contains all leaf partitions (because
publish_via_partition_root = false). Consequently,
pg_subscription_rel, which is derived from pg_publication_tables, also
contains all corresponding leaf partitions.  As a result, on HEAD, a
separate tablesync worker is launched for each leaf partition, and
each leaf partition is copied independently.

~~

Now, in Approach 4, when publish_via_partition_root is set to false,
we propose avoiding the inclusion of leaf partitions in
pg_publication_tables if their parent appears in the EXCEPT list.
Given the table hierarchy described in Approach1_challenges:

tab_root
├── tab_part_1
│   ├── tab_part_1_1
│   │   ├── tab_part_1_1_1
│   │   │   └── tab_part_1_1_1_1
│   │   └── tab_part_1_1_2
│   └── tab_part_1_2
│       ├── tab_part_1_2_1
│       └── tab_part_1_2_2
└── tab_part_2

If tab_part_1_1 is specified in the EXCEPT list, then
pg_publication_tables will include only those leaf partitions that are
not in the partition-chain of tab_part_1_1. As a result, both
pg_publication_tables and pg_subscription_rel (which is built from
pg_publication_tables via fetch_relation_list) will contain:

tab_part_1_2_1
tab_part_1_2_2
tab_part_2

With this setup, any INSERT into tab_part_1 or tab_root that routes
rows to tab_part_1_1_1_1 or tab_part_1_1_2 will not be replicated.
However, rows routed to any of the three leaf partitions listed above
will be replicated.

I hope it answers your query. If we have to go by Approach1, then do
you see any simpler way to overcome the challenges we mention for
publish_via_partition_root=true case. Or any other approach
altogether?

thanks
Shveta