Re: Skipping schema changes in publication

On Mon, 2 Feb 2026 at 17:18, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com> wrote:
>
> I reviewed v38-0002-handle-EXCEPT-TABLE-correctly-with-partitioned-approach-1.patch
> patch. Here are my comments:
>
> 4. While testing, I noticed that the new query introduced in tablesync
> can be invoked for "FOR TABLE". SHould we only call it for "ALL
> TABLES" publications?
> + if (server_version >= 190000 && !is_partition &&
> + lrel->relkind == RELKIND_PARTITIONED_TABLE)
> + {
> + resetStringInfo(&cmd);
> +
> + /*
> + * This query recursively traverses the inheritance (partition) tree
> + * starting from the given table OID and determines which leaf
> + * relations should be included for replication. Exclusion propagates
> + * from parent to child, and a relation is also treated as excluded if
> + * it is explicitly marked with prexcept = true in pg_publication_rel
> + * for the specified publications. The final result returns only
> + * non excluded leaf relations.
> + */
> Test:
> Create publication for table sc1.t1 using (publish_via_partition_root
> = true) and create subscription on it. In subscriber logs we can see
> the logs for the new query.
> sc1.t1 has the same structure as in comment 1.

We will not know if it is a table publication or all tables
publication from here. Also there can be a possibility of multiple
publications. We will invoke it and handle it from the publisher to
return appropriate tables.

Thanks for the review and detailed comments. All remaining feedback
has been addressed in the attached v39 patch.

In addition, the SQL query previously used to compute the set of
effective tables has been replaced with a C implementation. The SQL
approach had become increasingly complex and difficult to reason
about, especially as more publication combinations were added.
Implementing this logic in C significantly improves readability and
maintainability, and makes it easier to handle complex scenarios, such
as:
a) Multiple publications where one publication has no EXCEPT tables
and another does.
b) Multiple publications where one publication is an ALL TABLES
publication with EXCEPT, while another is a table-specific
publication.
c) Multiple publications where none of the publications define any
EXCEPT tables.

Peter's comments from [1] and Shveta's comments form [2] will be
addressed in the next version.
[1] - https://www.postgresql.org/message-id/CAHut%2BPsiWwmNSuCXTWM0iPDm3yGskLts-fukELTB__rbBids-A%40mail.gmail.com
[2] - https://www.postgresql.org/message-id/CAJpy0uAOvtMBP-oV9Tgoznt5-UsE2dzAjZW3eJmgKcU-X-vEzg%40mail.gmail.com

Regards,
Vignesh