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 1vTD6e-00EnBk-2D for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Dec 2025 05:51:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vTD6b-009sdd-0y for pgsql-hackers@arkaria.postgresql.org; Wed, 10 Dec 2025 05:51:17 +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 1vTD6a-009sdV-39 for pgsql-hackers@lists.postgresql.org; Wed, 10 Dec 2025 05:51:17 +0000 Received: from mail-pj1-x1036.google.com ([2607:f8b0:4864:20::1036]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vTD6Z-004CcT-0p for pgsql-hackers@lists.postgresql.org; Wed, 10 Dec 2025 05:51:17 +0000 Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-343774bd9b4so5174757a91.2 for ; Tue, 09 Dec 2025 21:51:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765345871; x=1765950671; 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=d92WXLW4q+2LlqjSaOObMeK6wPKeoAh6vDuu7G1eBYY=; b=LaBwS75krPjpLYmW5GCwxW6dnGHy9P6wm/igX/9ceiSeXJXCXdCjYyTkEqArhJvRPO SiL6+Dif7IeXLKrL4lc/sPBaUwFLeu/tgkmIT18dFtVedAmfaOr1Oc+EcSDRo/cnpDh1 WsUrrMGT8DTizwjBj2655kCtsam6Id5fsKHykJmIEnFoZoZeSRRS4/VT9WDWB7TgPlUK mTJ+xPJwN+cpwlxSd9g9hP/k/Yc/aiYA6ccIwNd/yttIkUjXRin7yc59X0d+fYHZK1gm A2G8nr2ZI2c+ss29D2EbL3pt+Es8Enm84p2X3Ae2PZzwUkFUfpiNigN5E9rjY4M641rC ePeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765345871; x=1765950671; 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=d92WXLW4q+2LlqjSaOObMeK6wPKeoAh6vDuu7G1eBYY=; b=fPJ3XZBcWp5ma6M1AeY6j3eQGQxzEJCwmI/FFCvg/EwluG/8B9qD4SCDcEBwdi4+mJ BmGbBpZGEsx079Bp1Q4DDdb4XVUAUFhyI1RJdIonGW+YZ66QlH5MgrqQjOssnxtsElux Yh2hz/1eTnRJebFKOeilYJI6RaH6mXMCkdFTY/7WBWv6uaJEF2v583Pkjj8BxeyMUltt q8T37/foIM6KD075OQBDojIdrwNbxIfF+FIH61LePddoHDq8glmVJA4dNmJF13dodDIS RM2SRaLEZ0U2uw7kZQzQD2ZIJO8Ovjq0SDXKeyccoe4DSuQ33+tcOk2ckt+8cxEe726m KHuQ== X-Forwarded-Encrypted: i=1; AJvYcCUTqIZGzW0XBGulB1OWIwBluT+3kiHyoNyC0MoDXNGKBJlsPIDmwwglYUDAt+sj05GbRGGCuEJ1oEv1FxKX@lists.postgresql.org X-Gm-Message-State: AOJu0YzSZKN4h48n4Fd/6ckWkpfmtoDsbDkD207/0vodUDVDqqzjtntV 3TwPFkWmStw4JTI2pvCqkrvs5+ny6eZ2XaSly3i6pAcymo5dGl7ZqA2vG3EyD48SqF7Y1A3080P zdBzK8+DC0D3L3CNvU2nPNa7byA9Iel4= X-Gm-Gg: AY/fxX4Szbjc2/PAjbzcX2k8jVrvIligMrYb3R83gd2uWhpYZVikRy3V3jCqeGX8Ei4 qTesC1TDpqaJRDxPMjz6URg9mjjhgykFN0ZPym/o5q8L7MsOd3HX9SR2xKbh2iPtcjZQ73JOTmI Uuvv+IjM6W57pG5YGCQ/P3Qde8bQnJAiQA9P052sbE82ZpjL7KMEQ2/vZOpBd16weXo6yxK2axs 42LF2tdbBg4l3qbKUzoaFaIXg3hY0lxY3aPUXOKoEu8uxhY2jlb84XI69wgNbq7P8MfDT3LPraC I9WWdG154utyBTmoTz42/eHKq/42tn+APjDnDBfCb/ehbWs6wR7kypqqOoUr81yiFTsZcbnK X-Google-Smtp-Source: AGHT+IF4ReCngFpYGNBS+c+4U49F0RYCF0yhKU/VapGfFHl/L7rF7rflyHot7wSvP+iAPdQZl+9J1W1KlQAj1u2OP1s= X-Received: by 2002:a17:90b:3a4e:b0:340:9cf1:54d0 with SMTP id 98e67ed59e1d1-34a72838e00mr1195258a91.1.1765345871301; Tue, 09 Dec 2025 21:51:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Wed, 10 Dec 2025 11:20:59 +0530 X-Gm-Features: AQt7F2r8wzZl0jhV29ebthibHgIPcUfJz6rFZUt1hgh1LG1cD0BcxctjCSQBpIs Message-ID: Subject: Re: Skipping schema changes in publication To: Shlok Kyal Cc: Amit Kapila , Peter Smith , vignesh C , "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 Tue, Dec 9, 2025 at 11:17=E2=80=AFPM Shlok Kyal wrote: > > > > I have removed the 0001 0002 and 0004 patches for now. Will post them > once 0003 patch is RFC. > Here is the update patch for "EXCEPT TABLE". > Thanks, I have not looked at new patch yet, but here are few comments for v29-003: 1) create_publication.sgml: Please add one more example in the example section for EXCEPT using 'all tables, and all sequences' after the last existing one. This is needed to show that ALL TABLES EXCEPT() and ALL SEQ are still possible in single command. 2) + excluded. Optionally, * can be specified after th= e + table name to explicitly indicate that descendant tables are exclude= d. + We may add: This does not apply to a partitioned table, however. (this will make it more clear similar to how existing doc has it for 'FOR TABLE' clause ). And then start details on partition. 3) When + publish_via_partition_root is set to + false, specifying a partitioned table or non-leaf + partition has no effect Can we simply say 'specifying a root partitioned table has no effect'. This will make it consistent as the previous sentence also uses the same term rather than 'non-leaf'. 4) tab_root is a partitioned table with tab_part_1 and tab_part_2 as its partitions. In the first case, I receive a WARNING because the user excluded tab_part_2 but its data will still be replicated through the root table: postgres=3D# create publication pub3 for all tables except (tab_part_2) WITH (publish_via_partition_root=3Dtrue); WARNING: partition "tab_part_2" will be replicated as publish_via_partition_root is "true" But in the following case, no WARNING is shown: postgres=3D# create publication pub4 for all tables except (tab_root) WITH (publish_via_partition_root=3Dfalse); CREATE PUBLICATION In this scenario, the user has excluded the root table, yet its data will still be replicated because publish_via_partition_root =3D false. Should we emit a warning in this case as well? Thoughts? 5) publication_add_relation: + if (pub->alltables && pri->except && targetrel->rd_rel->relispartition && + pub->pubviaroot) Can we please bring both the 'pub' conditions together, as that seems more understandable: if (pub->alltables && pub->pubviaroot &&...) 6) We have added pubid as argument to GetAllPublicationRelations to exclude except-list tables. We should change comment atop GetAllPublicationRelations() to indicate the same. We should extend this existing comment to say about except-list exclusion also. * If the publication publishes partition changes via their respective root * partitioned tables, we must exclude partitions in favor of including the * root partitioned tables. thanks Shveta