Re: Skipping schema changes in publication
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Andrei Lepikhov <lepihov@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Shlok Kyal <shlok.kyal.oss@gmail.com>, Ashutosh Sharma <ashu.coek88@gmail.com>,
shveta malik <shveta.malik@gmail.com>, "David G. Johnston" <david.g.johnston@gmail.com>,
Dilip Kumar <dilipbalaut@gmail.com>, Peter Smith <smithpb2250@gmail.com>,
"Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, YeXiu <1518981153@qq.com>, Ian Lawrence Barwick <barwick@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-02-26T02:56:38Z
Lists: pgsql-hackers
On Wed, Feb 25, 2026 at 7:09 PM Andrei Lepikhov <lepihov@gmail.com> wrote: > > On 25/2/26 08:04, vignesh C wrote: > > On Mon, 23 Feb 2026 at 16:46, Amit Kapila <amit.kapila16@gmail.com> wrote: > > The attached patch has the changes for the same i.e.a) Raises an error > > when attempting to attach a partition to a root partitioned table if > > that table is referenced in an EXCEPT clause of any publication. b) > > Adds support for dropping excluded tables using: ALTER PUBLICATION ... > > DROP EXCEPT TABLE. c) Adds support for replacing the exclusion list > > using ALTER PUBLICATION ... SET EXCEPT TABLE. > > The changes related to DROP EXCEPT TABLE and SET EXCEPT TABLE have > > been kept separately into patch 0002 for easier review. > > I discovered this patch, maybe not deeply enough. But one question raised. > > I usually work with multiple tables (sometimes hundreds, if not > thousands). EXCEPT clause might be quite rare. > I think it will be useful for users using ALL TABLES IN SCHEMA and ALL TABLES publications where they don't want to replicate the entire schema or database. > Some commands want to > extract only excepted tables from the publication using the following > pattern: > > 'SELECT ... FROM pg_publication_rel WHERE prpubid = <X> AND pr.prexcept' > > - check_publications_except_list() > - describePublications() > - getPublications() > - LoadPublications() / publication_has_any_except_table() > > That means pass through all the publication tables to find (usually) > nothing. It might be a costly operation, especially in the > LoadPublications routine. Maybe slightly change index > pg_publication_rel_prpubid_index a little and add 'prexcept' as a second > column there? It might avoid performance issues that may arise during > the upgrade. > Why do you think it can hurt when used via LoadPublications? That is done only one time when the first relsync entry is built, after that it is reused unless there is some DDL on the publication. Also, we are not expecting thousands of tables in the except list for a publication. So can traversing that few entries and that too first time when cache is built can impact performance in a noticeable way? If you think so, we can modify the index as you are suggesting but I was thinking if the number of entries is not large per-publication then why to permanently increase the size of the index. -- With Regards, Amit Kapila.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix miscellaneous issues in EXCEPT publication clause.
- 6b0550c45d13 19 (unreleased) landed
-
Change syntax of EXCEPT TABLE clause in publication commands.
- 5984ea868eee 19 (unreleased) landed
-
Add support for EXCEPT TABLE in ALTER PUBLICATION.
- 493f8c6439cf 19 (unreleased) landed
-
Allow table exclusions in publications via EXCEPT TABLE.
- fd366065e06a 19 (unreleased) landed
-
Add wait_for_subscription_sync for TAP tests.
- 0c20dd33db16 16.0 cited