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 1viWbv-008mcZ-2g for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Jan 2026 11:42:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1viWbu-006ukn-34 for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Jan 2026 11:42:55 +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 1viWau-006qsd-0O for pgsql-hackers@lists.postgresql.org; Wed, 21 Jan 2026 11:41:52 +0000 Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1viWar-001i2N-2k for pgsql-hackers@lists.postgresql.org; Wed, 21 Jan 2026 11:41:51 +0000 Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-385bdc72422so1016471fa.1 for ; Wed, 21 Jan 2026 03:41:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768995708; cv=none; d=google.com; s=arc-20240605; b=erhSjcf0lY9xR8R7PtxWIUyY1P9RJNrwJhvhuadUnqtrcfE3j4/FXFvMwA+YLHvm9w yPc3TFMKF4YI7rZf7SdKYHR1QRAQAE7dyLKAW76FQCyAnGI/8/skR8PBBzNNfb4XTRdY 6WIwbMkEMW+TtgLLOW588FkdJJV6numEFSggU7UW3HxWJBIjpobMDb67WCNxiQt20FGs cJKVCYKugcA+S7NFG2klaiXSSzWeLie7gTNbUDSTrO/baN/NDu+UaEwIjoHrx8p0GyoN /xn9gtGPKU5/XcnhQPAhlP4erel81CBKHmp4QND4ZSbUcYjTjVgUTssvrtp5hgjh34Qx x5Nw== 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=CKNDxmZntlV69lQ5H7LXTGSsMyIKY5Zij5rQaek2HCc=; fh=oOMxswBXMxPAduBhFgag48oUDlo5SG9NTmE9RejxDLo=; b=hJr6TDlS3st3Sk0z9eGunGfbGOTh4Npf7M0/MQo2YwRB1/SEh3ogSOp3eiyS9/ynqf PDK2EADU1r0UvrM+4zxnpW1xwknDVuG+R6Urq7X5QsmAP1JWdilaAEoocM5i3FhiouYS 8HDwSByuTFgHnFov8rf+G6k8g5h3W3UkA6321bBuiV2GMCEOQKX2zfGCk3SE0LlIc6mD f6X+aQN5K8yZPZcRdwzHiZdKs81BKJ93/htXGpkCDX1K0M/eXCcCwifEpEPPYLaVkTUU 1JzVB+U08d4G6n3JZK/DDw8uCZTgz2UXQLPo1+QHr7lbt4M5lRR5dKzpmetAlAcMa5Pt lAxA==; 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=1768995708; x=1769600508; 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=CKNDxmZntlV69lQ5H7LXTGSsMyIKY5Zij5rQaek2HCc=; b=VliwkpSkySUDeje/oxuuJym7xZfpWGDBdIfI8v8OncpTyquqD5+3XoZjFgCGvy8qCl 2J2hulM85xi5pmIgTIRnUlOO6eYl3/J8mFriKhade3OljS8jObpuTetQJsoCz8ictHxj Rbf2aga3cruLFdSf5bG1zYPz0pmLfq+HkJindrfJfgEwRz1JOwb2ovAYjWOBaHxZkh2d 3oEB0iUN4c2aVNh47Bka4typP5U7bDBgsfjuXjw8YqAHd4Gggsp+7/UNOr/dcjPUNZ37 WZGy/2dQ93M0d1bKhCgXhrRAv0jgx4U2jM1QZ1xUkmMa3bSLpplugtoMvDI77xXh++iL 6j/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768995708; x=1769600508; 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=CKNDxmZntlV69lQ5H7LXTGSsMyIKY5Zij5rQaek2HCc=; b=TvfXPqDtZayi5syYI6xp/mmJXAuNlEpw7PEo/e6BiMJNvwe/lahiZ3MfiL63hwja0I sNWWXxVm2DSo3R2hQ3tDheh7wZIeLiSp2k7KLG/zCeQVa4MbNuG2cfifn41T04KDT/vn S7CjZpGP5YYBgEHI8CBX4ZUwdKJx1oqCvEQMWXyQVggtw+3QNNWNErWax8rXPan9p3Ps 62iDCgj8COTbnwkWVjN9s4WloH8QTN6AXWg20/oPAqLZ0TcRTA4uVOFumbXH/IAjo7Gs xHK6bwbUjr8iSx1fhf0VSUJzwB5TS8SKWyJO9P6nrmLx0TQ/jzQws0tOIvjJglYUjCJK 6NzQ== X-Forwarded-Encrypted: i=1; AJvYcCWHFC6a3U+CvbBbcYRca+PvumWVkd7wXTyDm4KACTVjQhNEEauUknxG29tkmoD50Q9oEmDu/Om3tQW4zogR@lists.postgresql.org X-Gm-Message-State: AOJu0YyEi7i29A4nnrMkhlYVYQPvz6g841dJE8W7FuNawi9ajo0WeQ4v NujEPppy3wAWiY7L0WhYBOfMA5jZ/phYNzdw+UenXG77P4RGVJoKuK/obx/qV7Tq+xavhFYziAF 4jAklLjtdog84T/eaFScgiGl4alCH+5I= X-Gm-Gg: AZuq6aKjIFftLDj115n0Wjvlv2DsxlSprv2VVCZfCUDKPju8AuYKfTw8YaKnbq+IwJ5 a2kDLrZDXijEHpezKVQ+tlMPWleGc5AkWGwnhVj939d0AgLoCVNrhq02r5SGmBroQkWFEvBTiXq sqdfqgD+JS+6PjOmVXQyDffsaVXMYr2T2Fc0cwMA0z9YBdwXH1wtuGOgBRCkWyzahacc90L4XwU 5/s+728rPVA8fJ0ir54WxGzvJ71k24PasK69/e6yDu+mcSfOhmMsNBYgOnlOFAgVEsDLO4= X-Received: by 2002:a2e:be0d:0:b0:37b:96e5:dc40 with SMTP id 38308e7fff4ca-385a53b6c0dmr18993201fa.8.1768995708124; Wed, 21 Jan 2026 03:41:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dilip Kumar Date: Wed, 21 Jan 2026 17:11:31 +0530 X-Gm-Features: AZwV_QhiXUunM4bPek8o3y6bQFrav-tTdbrdUQgcn7JA9wiF_jXNPA-4I87lyEE Message-ID: Subject: Re: Skipping schema changes in publication To: shveta malik Cc: Amit Kapila , Shlok Kyal , Peter Smith , vignesh C , "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 Wed, Jan 21, 2026 at 4:57=E2=80=AFPM shveta malik wrote: > > On Wed, Jan 21, 2026 at 11:35=E2=80=AFAM Dilip Kumar wrote: > > > > Thanks for explaining this, overall I like the Approach 1, and I also > > see the problem when publish via root is given in that case COPY FROM > > is executed on the root and it would be hard to exclude specific > > partitions. What is the behavior when root of partition tree is added > > but publish via root is not true, it doesn't add any relation to > > publication rel or how does it manage to not copy data from > > partitions? > > > > So, I believe you are asking about the behavior of COPY on HEAD for > the following case: > > CREATE PUBLICATION pub1 FOR TABLE tab_root WITH > (publish_via_partition_root =3D false); > > In this scenario, pg_publication_rel contains an entry for tab_root, > while pg_publication_tables contains all leaf partitions (because > publish_via_partition_root =3D false). Consequently, > pg_subscription_rel, which is derived from pg_publication_tables, also > contains all corresponding leaf partitions. As a result, on HEAD, a > separate tablesync worker is launched for each leaf partition, and > each leaf partition is copied independently. > > ~~ > > Now, in Approach 4, when publish_via_partition_root is set to false, > we propose avoiding the inclusion of leaf partitions in > pg_publication_tables if their parent appears in the EXCEPT list. > Given the table hierarchy described in Approach1_challenges: > > tab_root > =E2=94=9C=E2=94=80=E2=94=80 tab_part_1 > =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 tab_part_1_1 > =E2=94=82 =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 tab_part_1_1_1 > =E2=94=82 =E2=94=82 =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 tab_part_= 1_1_1_1 > =E2=94=82 =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 tab_part_1_1_2 > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 tab_part_1_2 > =E2=94=82 =E2=94=9C=E2=94=80=E2=94=80 tab_part_1_2_1 > =E2=94=82 =E2=94=94=E2=94=80=E2=94=80 tab_part_1_2_2 > =E2=94=94=E2=94=80=E2=94=80 tab_part_2 > > If tab_part_1_1 is specified in the EXCEPT list, then > pg_publication_tables will include only those leaf partitions that are > not in the partition-chain of tab_part_1_1. As a result, both > pg_publication_tables and pg_subscription_rel (which is built from > pg_publication_tables via fetch_relation_list) will contain: > > tab_part_1_2_1 > tab_part_1_2_2 > tab_part_2 > > With this setup, any INSERT into tab_part_1 or tab_root that routes > rows to tab_part_1_1_1_1 or tab_part_1_1_2 will not be replicated. > However, rows routed to any of the three leaf partitions listed above > will be replicated. > > I hope it answers your query. If we have to go by Approach1, then do > you see any simpler way to overcome the challenges we mention for > publish_via_partition_root=3Dtrue case. Or any other approach > altogether? Thanks for the explanation, that clears it up. I agree that Approach 3 is the right path forward. And it makes sense to extend this with Approach 4. Logically, I think it's reasonable to say that if a user chooses to partition via the root, they are treating the entire partition tree as a single entity. Therefore, it makes sense to disallow the exclusion of individual child partitions in that context. --=20 Regards, Dilip Kumar Google