RE: Skipping schema changes in publication

From: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>
Cc: Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(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-25 06:33:10
Message-ID: TY4PR01MB169075BC5D58A363746C842569475A@TY4PR01MB16907.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Monday, February 23, 2026 7:16 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Feb 23, 2026 at 11:37 AM Shlok Kyal <shlok(dot)kyal(dot)oss(at)gmail(dot)com>
> wrote:
> >
> > I have also modified the error message as suggested by Shveta in [2].
> > Attached the latest v48 patch.
> >
>
> I see that the second patch (0002) brings complexity in the patch to
> deal with following points: (a) The first complexity is if one of the
> partitions is specified then how to compute the initial set of
> relations to copy when pubviaroot is true. This is complex because we
> need to exclude the partitions specified. (b) The other complexity is
> combining Except list containing partitions and other publications
> specifying partitions or partitioned tables both during replication
> and probably during initial sync.
>
> I think it will be better if for the first version, we allow only root
> partitioned table to be specified in the Except Table list. This would
> mean that if the user tries to attach that root partition table to
> another root then we should give an error. If we go via this route, it
> will be important to allow users to remove some tables from the Except
> list, so we can provide Alter Publication <pub_name> Set Except Table
> (table_names).
>
> I think excluding specific partitions may also have some use cases but
> adding additional complexity and maintenance effort is worth, if there
> is a real field demand for such a feature.

I agree that supporting exclusion of a partition while publishing its
parent would add significant complexity and could be achieved independently.

Another perspective I saw this is that the ability to exclude only a specific
partition from a partition tree while continuing to publish changes via the root
table introduces an entirely new mode that users couldn't achieve before this
patch. Previously, once a parent table was added to a publication, all its
partitions were published regardless of their schema, so users cannot exclude a
partition either via FOR TABLE or FOR TABLES IN SCHEMA. Therefore, disallowing
partition exclusion doesn't remove any existing capability, which seems
acceptable.

The original use case in this thread also doesn't mention partitioned tables, so
I think EXCEPT TABLE provides value even without implementing this new ability.
Given the amount of code required to support partition exclusion, it makes sense
to me to treat this as an independent feature that can be pursued later based
on user feedback.

Best Regards,
Hou zj

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2026-02-25 06:35:05 Re: Consider low startup cost in add_partial_path
Previous Message yangyz 2026-02-25 06:31:40 pg_basebackup: removed an unnecessary use of memset in FindStreamingStart