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 1vrqML-0091Lk-0W for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Feb 2026 04:37:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vrqMK-003dJu-0J for pgsql-hackers@arkaria.postgresql.org; Mon, 16 Feb 2026 04:37:20 +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 1vrqMJ-003dJl-1m for pgsql-hackers@lists.postgresql.org; Mon, 16 Feb 2026 04:37:19 +0000 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vrqMG-00000000pZW-44fs for pgsql-hackers@lists.postgresql.org; Mon, 16 Feb 2026 04:37:18 +0000 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-385cfc572f1so20517361fa.3 for ; Sun, 15 Feb 2026 20:37:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771216635; cv=none; d=google.com; s=arc-20240605; b=RZPNa/eW1lpTRXI5PKoLGHYDQ+ctBEq//3iLcNWEpw7ywcMFi/BrdepDCwlBb+o42K XUEMKQ/hqo3vWWZT0Y1vUxb/Jnr36F8AR1dY7LVjdnon0FbcCm+T5OcxDJm2KshUSZGG NgbtNSK/48/WZa3IW1NZGu2px6NjoaESpYoK32WI9D6FVS5617IKsUHOKxUxY6BRge6K 0Vnuc6Nf+lb+1A9AeaVOHIClAZTMgGpD3CAnrwBgrPglJB6vMlVV/dNGp5pBG3h+A6dH RA9mR8LEwa28A8bTP2oV5PIHMYLY1c/TCHmpgd9PKLzQLdkmaxqIt+R3ofZ42y4jHXkQ RPew== 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=eQ/pG7gf0W5y6LASfbGE2lTUnRPllG1PIoaGyPRrAYA=; fh=ar6HMXL0duFrMUv0yl3wN35ZTYO30uggI1yXuHwIO1M=; b=k57FtoJO6sP5LtLTC0R8mIFwVUGwayC3ocmYjKl4BnwI9KiGh1Jy0wiHGpowLaa4PJ /9LmPixcchaAeoXsSoE5a1RHBjOTorFj/+t7WDNFUKTZQ/8jYo8fjf6WYlrDaU60Yfgn NHMJJsDAL3R+u1Sbw8+QDY4aqKXS18eR544LO2ahGczNUoZ/KLY3a9UGDfIb5KfUm7o/ j6EFITo3BSgRUPvKNIctjvqdPSScic29X3lxgHdAiNBbIQalSEbtx3UdznQn3+S4qqCm FMV6UbKQEaohlGTHEArKokCKqTRr7D0AjGg7WrqrG2VZgWtdkWdYFyPuorPcJIFZnqtq Szkw==; 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=1771216635; x=1771821435; 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=eQ/pG7gf0W5y6LASfbGE2lTUnRPllG1PIoaGyPRrAYA=; b=A/mCAGHMFivLJF2HDsg4j6eWJzhHvzG1slHmB8jErVWhGxZ380mUOEpeNAAS9fEFzg xsrpecfnvZwdQATnLgC3O7GDpehLvqe6W+H/xVxhYPsqMJsThSeM9g5mc+ZF5lnM5oh7 /VwYHPJqDgum9+ZNwmE5FLqijiWzsACDVwhLiMBxWcbSSn5bh+Iug+7xXlqwDBnKW+PB n9pEBIWSXvIT8hUR7Sy1s1V5mTsmwtZ221FKn65utBkbmhOh1gV3OIDqXr/c8UZaSv/N BC9hKIpTIL9Qc/6PpNpl+caT4TSSzM2E4yhfv5SbbJIBdfwOneDsS/U8p+5n2woBxgaV cyeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771216635; x=1771821435; 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=eQ/pG7gf0W5y6LASfbGE2lTUnRPllG1PIoaGyPRrAYA=; b=tv4ttkJzMrsnnzTLm0Ujj1UvyC8jQODbdZNwYU4DrJs4HVw0mhDhe/uMFQOGyiLZFy V5s7j4luf4KQzH8xv4ZNKzmJ/L2CarVSuBDtDtzq0Hg9Pmyb+R0f1R/jaUzxNKS3YOAd hbES9ERrVQSeXQyTDArluYW4WW0c7jUPnW0DlqxDtVxRk6eQeKh/kOFCogbHMG2+q36B ZCOlUFLicMV5WldUz4OatesGT93ThhsKRSP5nr1u1fo2NPDUC8H1Z9dno8oUADdEZKl7 tTQ/vRgHUoPiBhp2Jgtg2qwlzV2N4EuZSAVHjpWx6u3GuGb68s5h4Dh9Wcovl69GABwr 3S3Q== X-Forwarded-Encrypted: i=1; AJvYcCX0UrML93hzgg14arsls8dz8HBGPD1PZ9F6HH++SvAyiFxPEDJYUweXwTBcRqO5TAEYZgwab5D1BB8u8kG6@lists.postgresql.org X-Gm-Message-State: AOJu0YxEbWLdG9iZjm/dK93VstPR141UQ0u9Vy+g5qcon7/qrWU9zN+D DUUAW9xYkR7EITa7aKHeR0kVbY1hRX177R4TQwLxlpzDBhyZcFdJD8QBkj/+c444EClrT5Vrm9w AGWy3CP+jUsvvJxicvfHC+b1wx2yu4mc= X-Gm-Gg: AZuq6aKX4OvR+vDtJODoLgAPgIz2CCQKwiOMbLqGPiDYqMsM1aVEAIQ0cBrzfm73WGF obJ0mmBsB8i+N/WNG5i8e5VNSodqBk8w1eCAisjz9pdKxnEdE+Yb6n3/t73jfKQZTlA/2tN8ezr 6wap0CbdUkuH9xY06xeK3zPn6UwT4SYactZ1oMGZEZjeXNcwYN+t1osguxLcZe3+egJv61fx3Pi vnWKI06fVv4N/5ZgPdsKSmAtikm+E0uxMDg9CH0//CKI/DJ3AyL7PLXMijCmb4XnHAgAvFycGYR r3p9GGMqPVjK1ASaolN8AZExqD4ShZ1406MZ7q1H8FwkFh15gw== X-Received: by 2002:a05:651c:1ca:b0:385:fbff:ab2f with SMTP id 38308e7fff4ca-38810526b00mr23104381fa.17.1771216634849; Sun, 15 Feb 2026 20:37:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Mon, 16 Feb 2026 10:06:58 +0530 X-Gm-Features: AaiRm51BhZ20IBdp0M5t76jTRSEewtZESUDTjJ-LlSxhYh2n0m3YqyS4yK2aIeY Message-ID: Subject: Re: Skipping schema changes in publication To: vignesh C Cc: "David G. Johnston" , Shlok Kyal , shveta malik , Amit Kapila , Peter Smith , "Zhijie Hou (Fujitsu)" , YeXiu <1518981153@qq.com>, Ian Lawrence Barwick , Bharath Rupireddy , PostgreSQL Hackers 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 8:50=E2=80=AFAM vignesh C wro= te: > > On Thu, 12 Feb 2026 at 13:58, David G. Johnston > wrote: > > > > On Wed, Feb 11, 2026 at 11:58=E2=80=AFPM Shlok Kyal wrote: > >> > >> > >> We have addressed the comments in the latest v43 patch. > > > > > > Non-comprehensive review. > > > > Shouldn't the early exits look like: > > > > > > if (list_length(publications) < 2) > > return; > > > > perform query here, capture except_publications > > > > if (list_length(except_publications) < 2) > > return; > > > > construct error message and ereport > > > > Modified > > > > > + if (publication_has_any_exception(puboid)) > > + { > > + except_pub_names =3D lappend(except_pub_names, > > + makeString(pubform->pubname.data)); > > + has_any_exclusion =3D true; > > + except_pub_id =3D pubform->oid; > > + } > > > > Either rename has_any_exclusion to has_any_exception or, given how ambi= guous that reads in code, maybe standardize on calling these exclusions thr= oughout the code and either just accept we've chosen EXCEPT for the syntax = for good reasons or consider whether to EXCLUDING (table1, table2) would be= a better choice. > > Changed it to has_any_exception > > > + errmsg("could not get non excluded table list for table \"%s.%s\" fro= m publisher: %s", -- triple negative; try to avoid "non excluded" as a term= - those are "included". > > > > pg_get_publication_effective_tables - the second input argument is an a= rray of publication names so the singular form here is a bit misleading. S= hould this be subscription-oriented? Otherwise, pg_get_tables_from_publica= tions seems like a more accurate name. "effective" or "only the included o= nes" seems reasonable to imply. > > We have used similarly in the existing pg_get_publication_tables, I > felt the existing might be ok to keep it consistent unless there is a > better consistent name. > > > Related, the check in there for "does at least one publication have an = exclusion list" makes sense but feels awfully similar to the check for "at = most one publication has an exclusion list"...too late for me to figure out= what if anything to do make/do about it though. > > Ideally this is not expected to happen. But under rare cases it can > happen if the publication is dropped/recreated with except after > creating a subscription. It is better to throw an error in these cases > as we do not allow multiple publications except tables. > > Thanks for the comments, the attached v44 version patch has the > changes for the same. 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 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. + 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? 2. + + Create a publication that publishes all sequences for synchronization, = and + all changes in all tables except users and + departments: + +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? 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? 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. 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? It means relation is not in the EXCEPT list or in the EXCEPT list? --=20 Regards, Dilip Kumar Google