Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vrsq3-00B3KR-2r for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Feb 2026 07:16:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vrsp3-0046N4-1f for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Feb 2026 07:15:09 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vrsp2-0046Mv-2z for pgsql-hackers@lists.postgresql.org; Mon, 16 Feb 2026 07:15:09 +0000 Received: from mail-pg1-x531.google.com ([2607:f8b0:4864:20::531]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vrsoz-00000000qbP-1Upn for pgsql-hackers@lists.postgresql.org; Mon, 16 Feb 2026 07:15:07 +0000 Received: by mail-pg1-x531.google.com with SMTP id 41be03b00d2f7-c6e1d55ca03so481895a12.0 for ; Sun, 15 Feb 2026 23:15:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771226105; cv=none; d=google.com; s=arc-20240605; b=V0lSoH+isDaBplr6+Cpy84bcGOq/SpxE2HdEeRi1qBQYal/vgWIXQ8NY6HZrZ128P2 VWuUZYHNvdSpjncqrKFXp8wIpAEO+ydypMkkCVg2OkfUOo4WHJsY53u2exVOKoyUxpS/ TnXoc3bU65avo4lY7HcfhVyBPUx/Ax5bNnCjauLW7QICccjZ1Gj+pqYk8vFkF/3bjNVD vfXcD0sonnh4Qk7BqMIx22gydr0F3XYgl5yd/HHztDqDDFMbriomxSEBZoNBDTClS6Rg VnJUN6Pfqa91bZKY0nWNi5iR25WIvj7/ABg8cAl49Fg1clrTEuGWfd6ncI9yX/+Wqb2a 37Mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=TDdgwCSO2CLtkK7VdlSJaMAaqqhGTr9/kDcDu0PXK70=; fh=Q4FhTQUJa1+YicAwuZyKFogMfoOhqwqHkJ2M5jlLe94=; b=O/nphzgzlp2OeQXmk0kgG+clIfs0glIReT0fDKqdfSUoOUAceFQzQbSZHLDmZCzama +kQG6pmcPECgV6JLHufvh7VUQZ2z0pGQcsWslQq5RBQyDNRdLgY8vv5W6mF72JWJQY/T ZHCu9E6oWN1+VUNvrX3BkQucxiPFanto7m7SKJU9sWZLfmqOZdtkmFToU6FdNEQr0sf5 hKZjrxiTcee4Mdi4hNBd0XnyVE8zWYlymf9cExMzrNzHaXaXxQasz1BxWc+GCb2RRDa1 DTyZijDQ1bzAZ9LNjM/RagTQMJ4ZfXLh4INY15WyQDgpgoAFmKtPKixvOPl2s/K9P+ib SI5A==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771226105; x=1771830905; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=TDdgwCSO2CLtkK7VdlSJaMAaqqhGTr9/kDcDu0PXK70=; b=S8cvl43k0wvcgmpu6rAtXGFRjTF0eGCr+s5Of9v77BEVd8MCZBXVH6h3w5nNoglO0u afcQbLiUaprKUdIt8iG6oxtAWWrGkuRmI8PWBjUbZNMakAXObX9Dv2iCiNCP+fIOHAdG UeT2yvtC2OwoqmmnpSUvMfxSWm8xokSOWmCZ2XdXDz85hki5nPdorm1YY3tElANclj6+ OnwmK0AaaE0BtEMNuOIpD7zuHkyNxSPnjKGJVLJK3ePkzfEldq7ReoTr+17y3E7bJ6IL a5w4KQNCsLgxX8hANUBElPxZt1gwTwFu6p0OrFJkhALJeiJT1yrCWS+XCTBW5FvnjRbI N3VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771226105; x=1771830905; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=TDdgwCSO2CLtkK7VdlSJaMAaqqhGTr9/kDcDu0PXK70=; b=NrBiJ+oNFcaiyIe9vpC4cMV/ZBKvzbvDeGR3msb/j09yDL3Gu3bJqL/xY/8PCQdtAZ Yl8cyusRqQh97YoR7qnblJ2L2oCL4iGjlcK9exOMK1tiVn/+tD5rUEm+NuygxyVCzyZB bvie8E55rGjZZMeNC5wKCnnUd9JO/LS5+9iKA3qfb5zpp8ZKQIgj6/Xvsleusfcd3GRo mTieHQZ5xXOOc5CfP06ii10EfQnEnPl/VWUkMhvSiDUBGQ6tlpzKbmsOPatoXvYIb7lr 6Qkuuu1EyM3hnlyQV6Io4VD3JYKz8MNUOXsQA4Oh7ZsxeN/hoYtfPA687hITctk90gfA f+UA== X-Forwarded-Encrypted: i=1; AJvYcCXo6dN9vTtwuco8q8141CgtG4DtKv7lU6eNTRqNVjuYsSEYnn67jvYFYohXZfEMHg8IQUoFREbiPRmCvcB4@lists.postgresql.org X-Gm-Message-State: AOJu0Yzrry5IbIcB1ZzFvNmnib9e9liCiMp3mNLvyNsINvMfluK+vP/7 //VrjfZm0vkIxJ308JyRoBg33vB7aOwnq/UUdCqXlu9YTKfAwRP021D8eRKz3wl0d2Q52lA4Asx M277tKhxMm9CjpKNkD1Hf7fZajW1D2Js= X-Gm-Gg: AZuq6aKdKrt4F7SjGlXfC3ySnRUg2umYqVy/KHNYN3/8GnbzveSxKhIBLlpHat22Dg0 G1jJ6fxh+4z0LLbL/zLJ2eoI9Ho9wJ+OAgw8zSU/dHK/FHMgvG8sfX/p5ff5kAMEEFjn3OX6c+x 8SDBGFOlmsXhg1S8b3LEFjxk4Dd/2kCizceVnv+UXEeuvTvgEf+/eIDT+UBz3auw1zZF0b6hnR3 7PbTRUWOXKgXHswfPoEdxcIYbX8NyWkctZ5Shcbf/xZ9BLd7jLUgi0D+A0i7T6i07CbQywyjYF7 PDPlEhQA441TS6zBGnA82MXiYK4Howy7e1MlC72+tMO+GV41HsAczc1y4fbqSefB X-Received: by 2002:a17:90b:1345:b0:34f:6312:f225 with SMTP id 98e67ed59e1d1-357b51ad2a6mr6680104a91.14.1771226105242; Sun, 15 Feb 2026 23:15:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Mon, 16 Feb 2026 12:44:53 +0530 X-Gm-Features: AaiRm53I0X4GGVBNBHJ7FP_QHbK2bXRjdOz061M9uyAKMjI-KvE8xqJjoeqRGeo Message-ID: Subject: Re: Skipping schema changes in publication To: "David G. Johnston" Cc: Dilip Kumar , vignesh C , Shlok Kyal , Amit Kapila , Peter Smith , "Zhijie Hou (Fujitsu)" , YeXiu <1518981153@qq.com>, Ian Lawrence Barwick , Bharath Rupireddy , PostgreSQL Hackers , shveta malik Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Mon, Feb 16, 2026 at 11:55=E2=80=AFAM David G. Johnston wrote: > > On Sunday, February 15, 2026, Dilip Kumar wrote: >> >> On Mon, Feb 16, 2026 at 8:50=E2=80=AFAM vignesh C = wrote: >> > >> I started looking into the patch, I have a few comments/questions >> >> 1. >> + >> + Similarly, if another publication includes the same table with a = row >> + filter, but it is also covered by a >> + FOR ALL TABLES ... EXCEPT publication, the tab= le is >> + published without applying the row filter, since row filters cann= ot be >> + specified for FOR ALL TABLES ... EXCEPT public= ations >> + and such publications are therefore treated as having no row filt= er. >> + >> >> 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 concur the wording is tough to parse. =E2=80=9CCovered=E2=80=9D is pro= bably not a good word to use. Stick with either included or excluded. In = this case, the point being communicated is if two publications include a ta= ble and one doesn=E2=80=99t have a where clause a combining subscription wi= ll consider the where clause to be a constant true when combining the where= clauses using OR. > > This wording basically already exists in create subscription. --yes, it exists already in doc ([1]) in the row-filter page. > This paragraph and the preceding one, which discuss =E2=80=9Cif another p= ublication exists=E2=80=9D, seems out of place in the create publication do= cumentation. This page should be restricted to only those behaviors that m= anifest when dealing with a single publication, detailing what it produces. If we want to mention it in brief, I still feel CREATE-PUBLICATION page is a good place. SImilar to how we mention in 'publish_via_partition_root' section. See 'There can be a case where a subscription combines multiple publications.' in [2]. Overall, I think this complete paragraph could be removed from CREATE-PUBLICATION. I find it over-detailed. + + When a partition is listed in the EXCEPT clause o= f a + FOR ALL TABLES publication with + publish_via_partition_root set to + true, the root partitioned table remains included= in + the publication. If that partition is explicitly included by another + publication with publish_via_partition_root set t= o + false, its changes are still replicated. In this + case, the changes are published using the identity of the root + partitioned table, since it is the top-most ancestor included in the + FOR ALL TABLES publication, thereby ensuring + consistent routing of changes within the partition hierarchy. + + + Similarly, if another publication includes the same table with a row + filter, but it is also covered by a + FOR ALL TABLES ... EXCEPT publication, the table = is + published without applying the row filter, since row filters cannot = be + specified for FOR ALL TABLES ... EXCEPT publicati= ons + and such publications are therefore treated as having no row filter. + Instead we can have something like below: There can be a case where a subscription includes multiple publications. In such a case, a table or partition that is included in one publication and listed in the EXCEPT TABLE clause of another is considered included for replication. Subscribing to multiple publications with different EXCEPT TABLE lists is currently not supported. ~~ I feel it is unnecessary to mention row filters or column lists specifically in the context of the EXCEPT TABLE clause because IIUC: --They do not apply to FOR ALL TABLES publications, which is where EXCEPT TABLE is relevant. --In the case of multiple publications, the behavior of row filters and column lists remains unchanged from the HEAD behavior. The EXCEPT clause simply excludes the specified table; rest of the behaviour remains the same. Thoughts? ~~ Few other comments on doc: 1) catalogs.sgml: prexcept: + True if the relation is excluded from the publication. We shall use the term 'table' instead of 'relation' to refer clearly that it is a table and not a sequence. 2) logical-replication.sgml: + . When a publication i= s + created with FOR ALL TABLES, tables can be explicitl= y + excluded from publication using the + EXCEPT TABLE + clause. Suggestion: 'tables can be explicitly' --> 'a table or set of tables can be explicitly' 3) create_publication.sgml: + For inherited tables, if ONLY is specified before= the + table name, only that table is excluded from the publication. If + ONLY is not specified, the table and all its descendant + tables (if any) are excluded. Optionally, * can b= e + specified after the table name to explicitly indicate that descendan= t + tables are excluded. + + + For partitioned tables, when a table is specified in EXCEPT TABLE, t= hen + changes to that table and all of its partitions (that is, the entire + partition subtree rooted at that table) are not replicated. This beh= avior + is the same regardless of whether + publish_via_partition_root is set to + true or false. The + publish_via_partition_root setting only determine= s + which relation is used as the publishing relation for replicated cha= nges, + and does not affect exclusion semantics. a) Can we make the tone of both paragraphs the same? Suggestion: For partitioned tables, if a table is specified in EXCEPT TABLE, that table and all of its partitions (that is, the entire partition subtree rooted at that table) are excluded from the publication. b) This behavior + is the same regardless of whether + publish_via_partition_root is set to + true or false. The + publish_via_partition_root setting only determine= s + which relation is used as the publishing relation for replicated cha= nges, + and does not affect exclusion semantics. I think there is no need to explicitly mention the 'publish_via_partition_root' thing here, unless others think otherwise. ~~ [1]: https://www.postgresql.org/docs/current/logical-replication-row-filter= .html#LOGICAL-REPLICATION-ROW-FILTER-COMBINING [2]: https://www.postgresql.org/docs/current/sql-createpublication.html#SQL= -CREATEPUBLICATION-PARAMS-WITH-PUBLISH-VIA-PARTITION-ROOT thanks Shveta