| From: | vignesh C <vignesh21(at)gmail(dot)com> |
|---|---|
| To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
| Cc: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, YeXiu <1518981153(at)qq(dot)com>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Skipping schema changes in publication |
| Date: | 2026-02-17 06:35:47 |
| Message-ID: | CALDaNm1KRCcR5jr=3aP0M3fv1pMNAZre9mSuQw8zw58gzuF9dw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 16 Feb 2026 at 10:07, Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> I started looking into the patch, I have a few comments/questions
>
> 1.
> + <para>
> + Similarly, if another publication includes the same table with a row
> + filter, but it is also covered by a
> + <literal>FOR ALL TABLES ... EXCEPT</literal> publication, the table is
> + published without applying the row filter, since row filters cannot be
> + specified for <literal>FOR ALL TABLES ... EXCEPT</literal> publications
> + and such publications are therefore treated as having no row filter.
> + </para>
>
> I did not understand what this paragraph is trying to explain? what
> do you mean by it is covered by FOR ALL TABLES ... EXCEPT, does it
> mean the relation is not excluded by EXCEPT?
I have removed these as they follow the existing row filter rules
already mentioned.
> 2.
> + <para>
> + Create a publication that publishes all sequences for synchronization, and
> + all changes in all tables except <structname>users</structname> and
> + <structname>departments</structname>:
> +<programlisting>
> +CREATE PUBLICATION all_sequences_tables_except FOR ALL SEQUENCES, ALL
> TABLES EXCEPT (users, departments);
>
> Do we support EXCEPT SEQUENCES as well or that's for the future?
We don't support sequences, it will be handled later.
> 3.
> +/* Helper: Check syscache for prexcept flag */
> +bool
> +is_relid_published_as_except(Oid relid, Oid pubid)
> +{
>
> IMHO the function name doesn't look great for its purpose, we just
> want to check whether the relid is excluded, published_as_except seems
> confusing, no?
Modified it to is_relation_excluded
> 4.
> +/*
> + * Throws an ERROR if multiple publications with exceptions are found.
> + *
> + * This check is mandatory because logical replication currently does not
> + * support subscribing to multiple publications if more than one of them
> + * uses an exclusion list.
> + */
>
> IMHO explaining the reason why this is not supported or giving
> reference to any other comments where it is already explained would be
> useful.
Updated comments
> 5.
> + /*
> + * If the root ancestor is covered by a FOR ALL TABLES
> + * EXCEPT publication that uses
> + * publish_via_partition_root, we must publish changes via
> + * the root identity.
> + */
> + if (root_published_via_exceptpub)
> + {
> + pub_relid = root_ancestor;
> + ancestor_level = list_length(ancestors);
> + }
>
> I find this comment a bit confusing, what does "covered by a FOR ALL
> TABLES EXCEPT publication" means? It means relation is not in the
> EXCEPT list or in the EXCEPT list?
Updated comments to:
/*
* If the root ancestor is effectively published by an
* ALL TABLES publication with publish_via_partition_root,
* then changes for its partitions must be published
* using the root identity.
*
* This applies even if other publications do not specify
* publish_via_partition_root, provided the root is not
* excluded from that ALL TABLES publication.
*/
Thanks for the comments, these are addressed in the v45 version posted at [1].
Additionally the v45 version also addresses Nisha's comments from [2].
[1] - https://www.postgresql.org/message-id/CALDaNm11LKbC2epEyHOvD6H_ONqLqhDQk7sXWwcneyhrTbFaTw%40mail.gmail.com
[2] - https://www.postgresql.org/message-id/CABdArM4KucFdHYPFCcpvpN7_OVnV5rpnDY7Daz7Cjn6ZuN-dkg%40mail.gmail.com
Regards,
Vignesh
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2026-02-17 06:39:22 | Re: Row pattern recognition |
| Previous Message | shveta malik | 2026-02-17 06:33:11 | Re: Improve pg_sync_replication_slots() to wait for primary to advance |