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 1vrs2e-00AODS-2x for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Feb 2026 06:25:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vrs2d-003umW-2A for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Feb 2026 06:25:07 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vrs2d-003umM-0z for pgsql-hackers@lists.postgresql.org; Mon, 16 Feb 2026 06:25:07 +0000 Received: from mail-oi1-x22a.google.com ([2607:f8b0:4864:20::22a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vrs2b-00000000yCB-13Us for pgsql-hackers@lists.postgresql.org; Mon, 16 Feb 2026 06:25:07 +0000 Received: by mail-oi1-x22a.google.com with SMTP id 5614622812f47-463a0e14b4cso762254b6e.1 for ; Sun, 15 Feb 2026 22:25:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771223103; cv=none; d=google.com; s=arc-20240605; b=MNFvHzu9LLotCKQ+tg4v+yDA0DY+PquUo1vPnjBpiGvdhjoSYYOI8voHvtfH6BWrMe +rp5Lrf3p9DsfAvsXDdNIc4au7KYdX3Pk2YHXr/zBhO/vKZSjU9N1wXC7st/E5GlYEFO oQdolbLaNv5ZzNFoV8kGeRuhry60ZiauKYulJYjq+bXgkbYrbHSGy3hdCtS9suR2k0sj es3RMh1Fkh8MAflAOjrm+3P0xysgtyIG1N0P1Rn8QZABsllcYXKO9A3ZjJV7kKnEAnnw T/OKfA5ASWtTchugCj26Hm9J41pdf2oMqR+JmKZCOoxeSRi4rwv4XhLWPBDcJGajAXtC v8HQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=nR0c77bqKeuNVkfBVo3pOg4wwGrqaH2VlnJSgw3tcdg=; fh=YuSiuUj2zcxu0ovl0DnwYukaSkBRmiWzBhJ8mwDgklo=; b=GfHKflnBJnh5SFoJHClr0exz3fgXdi1jGkboRV8w7fhA0xD/5QK5cd8LZuk8iumwef X8DETn6bxn5qpCude+MblipW5HMitEyq2sT4XQNpWIsSY/z90ECLjZwi9tjZS+1c11kg TzV/MyjIUBKbmlWXWxLUjwJdt8LvwqhnGsC/3FmAol6WKkV11XrwYCPWagdx/CZyTj8F aB1Zz1Mh6pYuq7EIVaCeERls+DQQx7sKCuOjKpkznMsWv9wyzezbkMDdxVgBSzvBoMmD H82XNxvnxZJk3cT/xlmQH9XMFsSFIdYqlilZ0jTpegmmIX5uA5EahR0Vm67skTaMetgM YBTQ==; 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=1771223103; x=1771827903; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nR0c77bqKeuNVkfBVo3pOg4wwGrqaH2VlnJSgw3tcdg=; b=cvmalZriipo1kHRBQeK4AwzppbKTSe1P1ZCPVCG0jHSMa+YYj/RCP8fRfhPdrtTmoS VCubEfFTAVTH6U+uIZlDr9Ej1q3zHZlafyDaMkWITjNPMg2hFDX7g4gtueTvYPE8n+QH BXVudRmZwn5T7V8gCaaHJ5UlzgZholUMkOnRdENdibX8v/ybWMGw4CGN8jmEJZ6hXNpw oLxRsHNHom7Zo2NlHDCBALbmlyEjyhs3x4YKeLhk19hYUkPe+EqoYyI5Rhpv+Bi9Ecnx DRADRkGUiwNO15YHC8prce3LnhrIvQA/4Aqb7vn5WQwbG/1K8Dfy19YRVrnKnt5iMgQk zcWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771223103; x=1771827903; h=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=nR0c77bqKeuNVkfBVo3pOg4wwGrqaH2VlnJSgw3tcdg=; b=vk8pEFewH60bEMq2L5ZYPulXycC158qsB4u0XMVdvvoCRA8ZkSyltc9rXB8g+FVxPT 76nNoONJ8o5y2sqtrq9HQqqMS/M2OgUz4ldbRK2m4YFciqMJx2T4H0xd7vbQ12iPKOvf nxGCsQ1fh99obwNoQYcuCd5BVov+TS93eND9qS23ZuUCs+jX0DBhI71Hx04YUdRheMMk rXFsHyKCPLsZl9QVYdI49tYtf6lE9ZW4koxr0dfjN5QhptYb8h3WUto6uSXYHeF0Ilo9 E6ZO/H4bsphP9eG+iaOaM1WITUBVuGwF0eiIXADbHOetPpY0/kYGeZBF4p2t3S298qAc ZUGw== X-Forwarded-Encrypted: i=1; AJvYcCUNC53MsLskIum+xkwwTEWeyAZ3g5qTmVcQZeGrzhaUA/SZcLMjyrb0FlkkXmjY2dQFUl6rJnrXUHIuz/5L@lists.postgresql.org X-Gm-Message-State: AOJu0Yy8c02DOuZpv+2FTUi2I6/MRIN0GvHW7m2mRPRtuK0BJf7ujDVM k1wRLr7ByvFJVcopPf9xRUL9Mh1QI3Txls0CGXz93wguJ6R/kTq/6C8BhtKes9frZARKdEFnDJm +ti2j5MtXyamJhzsTwdhUbkMKRWdKbIw= X-Gm-Gg: AZuq6aIs3MV5h91nSBDqG94l1GiuAwOwRlJirL4E5LlPXs/7gLkBBWaebWnQSm4mNBi bc7enAHDpBF61Bd0ZgXRbFejddnKhpjVaXeChmWceBR1qpOghkrlXhVKlbenUApWb+39rZ2q7D4 fAE034L/YkOImBX+UJTpTGsead75cN/Iq8E2+EeRbp4pNYdJ8l/RlunXCvqqCCx4z5Oc0vRGHlF OvvgNMZYa2G5tRqi1KVcrEByaAMa9Cj4XjpapC3VGk7k69j4eeZ9U6VdjIDrp/xHm3a5tqwqFtB jQK09JKERAXJ01a76AE= X-Received: by 2002:a05:6808:1a1c:b0:45f:4610:fc72 with SMTP id 5614622812f47-4639f1e7ffbmr4016784b6e.39.1771223103312; Sun, 15 Feb 2026 22:25:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "David G. Johnston" Date: Sun, 15 Feb 2026 23:24:27 -0700 X-Gm-Features: AaiRm53AybjAF_27UOmb8bqCrN-CYwTBSstN6kmKE-gLWjGlciifjXJ_kAI6LsI Message-ID: Subject: Re: Skipping schema changes in publication To: Dilip Kumar Cc: vignesh C , Shlok Kyal , shveta malik , Amit Kapila , Peter Smith , "Zhijie Hou (Fujitsu)" , YeXiu <1518981153@qq.com>, Ian Lawrence Barwick , Bharath Rupireddy , PostgreSQL Hackers Content-Type: multipart/alternative; boundary="000000000000e41a37064aeb030e" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000e41a37064aeb030e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sunday, February 15, 2026, Dilip Kumar wrote: > On Mon, Feb 16, 2026 at 8:50=E2=80=AFAM vignesh C w= rote: > > > I started looking into the patch, I have a few comments/questions > > 1. > + > + Similarly, if another publication includes the same table with a r= ow > + filter, but it is also covered by a > + FOR ALL TABLES ... EXCEPT publication, the tabl= e > is > + published without applying the row filter, since row filters canno= t > be > + specified for FOR ALL TABLES ... EXCEPT > publications > + and such publications are therefore treated as having no row filte= r. > + > > 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 proba= bly 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 table and one doesn=E2=80=99t have a where clause a combining subscription will consider = the where clause to be a constant true when combining the where clauses using OR. This wording basically already exists in create subscription. This paragraph and the preceding one, which discuss =E2=80=9Cif another publicat= ion exists=E2=80=9D, seems out of place in the create publication documentation= . This page should be restricted to only those behaviors that manifest when dealing with a single publication, detailing what it produces. > > 4. > +/* > + * Throws an ERROR if multiple publications with exceptions are found. > + * > + * This check is mandatory because logical replication currently does no= t > + * 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. The word =E2=80=9Cexceptions=E2=80=9D needs to be turned into =E2=80=9Cexce= pt clauses=E2=80=9D or =E2=80=9Cexclusions=E2=80=9D. > > 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 =3D root_ancestor; > + ancestor_level =3D list_length(ancestors); > + } > > I find this comment a bit confusing, what does "covered by a FOR ALL > TABLES EXCEPT publication" means? root_published_via_exceptpub =E2=80=A6 shouldn=E2=80=99t this just be =E2=80=9Croot_published_via_alltables? It=E2=80=99s the all table clause th= at prohibits " where" and accepts "except". IOW, it's sufficient to drop mention of except because the nature of the boolean means that 'false =3D=3D except'. Something Like: When dealing with multiple publications in a subscription, a publish_via_partition_root attribute on an ALL TABLES publication causes the system to direct the data for all subscribed partitions to the partition root, even if other publications do not specify publish_via_partition_root (so long as the partition root in question hasn't been excluded from the ALL TABLES publication). Note: all tables + publish_via_partition_root =3D false comes to mind here but I'm unable to dive into the sidebar at the moment. It seems like root_published_via_alltables being false covers that case sufficiently though since in effect the root isn't published in that scenario. + * If the relation is a partition, check whether the current + * relation or any of the ancestors is included in the EXCEPT + * TABLE list. If so, do not publish the change. This is done + * irrespective of pubviaroot setting. I don't understand the motivation for pointing out pubviaroot here. Of course a table that is not published doesn't care what 'pub'viaroot says. + * If the top-most ancestor is covered by a 'FOR ALL TABLES + * EXCEPT' publication, we don't need to track per-relation + * metadata here. These publications apply globally and do not + * support row filters or column lists that would require + * specific tracking for this partition. Suggestion: /* Partitions whose top-most ancestor is being published via an ALL TABLES publication need not be individually published via any other publication. Repeated occurrences of a partition take the least restricted definition, which the ALL TABLES publication always provides. I.e., all columns, all rows, no children left behind. */ if (root_published_via_alltables) continue; The last two sentences are inferrable (from the definition/description of the rules of publication combining) and probably should be excluded. If the root is either "except'ed or there is no "publish via partition root" this is false and the subsequent lappend happens per usual. That seems correct. + * explicitly specified in the EXCEPT claus of the given publication. s.b., "clause" David J. --000000000000e41a37064aeb030e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, February 15, 2026, Dilip Kumar <dilipbalaut@gmail.com>= ; wrote:
On Mon, Feb 16, 2026 at 8:50=E2= =80=AFAM vignesh C <vignesh21@gmail.com> wrote:
>
I started looking into the patch, I have a few comments/questions

1.
+=C2=A0 =C2=A0 =C2=A0<para>
+=C2=A0 =C2=A0 =C2=A0 Similarly, if another publication includes the same t= able with a row
+=C2=A0 =C2=A0 =C2=A0 filter, but it is also covered by a
+=C2=A0 =C2=A0 =C2=A0 <literal>FOR ALL TABLES ... EXCEPT</literal&= gt; publication, the table is
+=C2=A0 =C2=A0 =C2=A0 published without applying the row filter, since row = filters cannot be
+=C2=A0 =C2=A0 =C2=A0 specified for <literal>FOR ALL TABLES ... EXCEP= T</literal> publications
+=C2=A0 =C2=A0 =C2=A0 and such publications are therefore treated as having= no row filter.
+=C2=A0 =C2=A0 =C2=A0</para>

I did not understand what this paragraph is trying to explain?=C2=A0 what do you mean by it is covered by=C2=A0 FOR ALL TABLES ... EXCEPT, does it mean the relation is not excluded by EXCEPT?

I concur the wording is tough to parse. =C2=A0=E2=80=9CCovered=E2=80=9D i= s probably not a good word to use.=C2=A0 Stick with either included or excl= uded.=C2=A0 In this case, the point being communicated is if two=C2=A0publications include a table and one doesn=E2=80=99t have = a where clause a combining subscription will consider the where clause to b= e a constant true when combining the where clauses using OR.

=
This wording basically already exists in create subscription.=C2= =A0 This paragraph and the preceding one, which discuss =E2=80=9Cif another= publication exists=E2=80=9D, seems out of place in the create publication = documentation.=C2=A0 This page should be restricted to only those behaviors= that manifest when dealing with a single publication, detailing=C2=A0<= /span>what it produces.
=C2=A0

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 =3D root_ancestor;
+ ancestor_level =3D list_length(ancestors);
+ }

I find this comment a bit confusing, what does "covered by a FOR ALL TABLES EXCEPT publication" means?

=C2= =A0
root_published_via_exceptpub =E2=80=A6 shouldn=E2=80=99t this= just =C2=A0be =E2=80=9Croot_published_via_alltables?=C2=A0It=E2= =80=99s the all table clause that prohibits "where"= ; and accepts "except".=C2=A0 IOW, it's sufficient= to drop mention of except because the nature of the boolean means that = 9;false =3D=3D except'.

= Something Like:
When dealing with multiple publication= s in a subscription, a publish_via_partition_root attribute on an ALL TABLE= S publication causes the system to direct the data for all subscribed parti= tions to the partition root, even if other publications do not specify publ= ish_via_partition_root (so long as the partition root in question hasn'= t been excluded from the ALL TABLES publication).

Note= : all tables=C2=A0+ publish_via_partition_root =3D false comes to mind here but I'm = unable to dive into the sidebar at the moment. It seems like root_publi= shed_via_alltables being false covers that case sufficiently though since i= n effect the root isn't published in that scenario.

+ * If the = relation is a partition, check whether the current
+ * relation or an= y of the ancestors is included in the EXCEPT
+ * TABLE list. If so, d= o not publish the change. This is done
+ * irrespective of pubviaroot= setting.

I don't unders= tand the motivation for pointing out pubviaroot=C2=A0here.=C2=A0 Of course = a table that is not published doesn't care what 'pub'viaroot=C2= =A0says.

+ * If the top-= most ancestor is covered by a 'FOR ALL TABLES
+ * EXCEPT' pu= blication, we don't need to track per-relation
+ * metadata here= . These publications apply globally and do not
+ * support row filte= rs or column lists that would require
+ * specific tracking for this= partition.

Suggestion:
/* Partitions whose top-most ancestor is being published vi= a an ALL TABLES publication need not be individually published via any othe= r publication.=C2=A0 Repeated occurrences of a partition take the least res= tricted definition, which the ALL TABLES publication always provides. I.e.,= all columns, all rows, no children left behind. */
if (root_publis= hed_via_alltables)
=C2=A0 =C2=A0 continue;

=
The last two sentences are inferrable (from the definition/description o= f the rules of publication combining) and probably should be excluded.

If the root is either "except'ed=C2=A0or there is= no "publish via partition root" this is false and the subsequent= lappend happens per usual.=C2=A0 That seems correct.


+ * explicitly specified in the EXCEPT claus of the gi= ven publication.
s.b., "clause"

David J.

--000000000000e41a37064aeb030e--