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 1viWNF-008fi1-1I for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Jan 2026 11:27:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1viWNE-006kt9-1j for pgsql-hackers@arkaria.postgresql.org; Wed, 21 Jan 2026 11:27:44 +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 1viWNE-006kt0-0K for pgsql-hackers@lists.postgresql.org; Wed, 21 Jan 2026 11:27:44 +0000 Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1viWNB-001aIS-1V for pgsql-hackers@lists.postgresql.org; Wed, 21 Jan 2026 11:27:43 +0000 Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-352e2156450so661355a91.3 for ; Wed, 21 Jan 2026 03:27:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1768994861; cv=none; d=google.com; s=arc-20240605; b=CJ+gOzDRcByMpibsYkbidwR75oxPdYjOrPxaIKLVwDExEGUVoWMNjRYJ+YQh/DdH3n l+dsRAD4EM2BLq39IKkT75izcjvfPUIlok5LBkqnY9MfKHIfZlGyVsn2jH9N5mvo/qiA Ey2n5sTx4EfJBQ3mO3S+LRUndR00YS9KUJhtjHB5EpewABamTViwqN3ri5aeQBGaCjJT OsJHKSoHB8yQUQgn0YT6qE4UHNnY6EbhhIQhIyVWC+naJY06UmVqNvmfW8qrHJJ2h9wT GOoR2ZTkRT8y7GvBUPG++Zy/AfeS7d8t7ljQe+pRjzaC38dlQt7zCZWEaS2Y2ReMuM/d cUWw== 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=23No8NjL6YWt44+RobWY/iFbrJKYjibRPrjbIgRpjvo=; fh=rTGYP8Nq6lyO5uetmX27qwOXQS/5i6HKUsYO2T0HM/g=; b=BIpIa9eUSin87+PmPInF4m1Ptqqo4YqKugpe+ODElJKhwN6/QdZeFlHGsvsYVLzKHq eufag0i8zSGP2UshYwJvCm4rAp61Iq8SyYGGe3qZH50sMEKmUc84NjAlgpv+GChUfqmQ 723VBj+r1vEcT4Qfa/sEYmc+WeU/84e7jwupqkeX/2NqVB+DeLUMabXt3mLjX3XHH5/3 Pv4Sg1MlA1gyS9jTjH33H1rH3O5jtU7nljzIUQsDwgYQC2/QK3VtAvhxsjQSPiN4W0IH 9xayNmtQ5Af2oVyIE/O99urUFGPQUnw0joN91unaLmNycPG6EKMEfscQbqvktbUB1gfV D3fQ==; 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=1768994861; x=1769599661; 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=23No8NjL6YWt44+RobWY/iFbrJKYjibRPrjbIgRpjvo=; b=liiOi8YIhOvd0Tb3j7nlLUXvyxzEdEZErNZ68vvJxg5QkDWy+K+87wLf6keNzs9MU4 9Se9/rVOK6CRn17kk7k8baCY8V1jtGfT96YE8CiPBvLHKcPKh+2HOOfQ/PaUvmuvyyB8 Jl2BsrsXNWGoVDM1rBKNJTB+Jely6FrKjnJ/sPuE2lwf32Q744KrELxLKAzKW8RG4Mpf BH/gfk3IEyWgQqPQFArv4FT5k286OdiaU9SHsjoTNAd0EuMp/xzjrzFreTGM2lOv7dX8 wc/TUXCFtWB/gXf/7isZRlbaylgTz3gMdCEf8HlUmuKtPuoUETk0HsaDjCOt5y8GVtnT SuDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768994861; x=1769599661; 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=23No8NjL6YWt44+RobWY/iFbrJKYjibRPrjbIgRpjvo=; b=gj/FrDz6FN51U562nTlPSXfADDVdwxUwACyD+Digaya2a6SbwLr39zsZ8rdQ0HFMg3 k/AYOLIS1FNfV4GLKo0EqaoxzMNCwg9eN+MYDY1/Qj83Hqk35dwDk+IGR97MPzMIBp1R aLgPV+2fRB4s+356tXU94GeMWSwXEUjYKpa24xccpfL4CcOf+c5rC7XQuum2tY/ZJ6N/ rfQ/D7bUBtbXHkD2n4tyaTZAcCtvUS/mi/29K6Oz4EAa1dsoR+9uwesG8SxyG9pCuTWH QdlpheUJC1n05Nib0KbMFPBMsz4VG0CusNpj/PnvX9FCbxBokfnU8uow9PIk8+UmZrFj hhdw== X-Forwarded-Encrypted: i=1; AJvYcCVUXG3Kj6eHPsJRh/606XTyx9GoqhJRr0wClHFoAI5sEipz1VZKcK6M+ESaPNEwAP9QQK5pPqM8q7Vv2MDp@lists.postgresql.org X-Gm-Message-State: AOJu0YxzrTyEk6zCXnfP48YR9j6XzkgY46aDJ5N8y4/61p/KADootcmY VnibgzQsdmeO4eO7z1uH9htcJPR1Z/Ws58/BVI56wP5Ypoov9ileQqVb7S9N6/PqBc6+XPWlcBE qIH59fnzqHAsr5G4BoWVjOk6WYJv/vLU= X-Gm-Gg: AZuq6aLuR4M8SWyAZtDIWJMoVLOOQ4O7y+u331XMt6nWzCkosUALbrXqpWBzQocQEjK yJLPyz7atoFMFrBVcCgc7Hgk+xMSqDLUhppKBhOqDq2axg99UpfYbPVJEaQ2C6W16ZR77ol1ZiL dGhu+4bfg51JOqa4dQ9h9jcnQvSxU7MIShACgvpTE/VKjRUrNxRo2QIPe6x3i/2IGYUUKecQVZt U4MlwFtLRWSQZF0PlhQJLEpCCphfi7ROt7osrB37/Dw920vGtdQWnZW/e/epvdUsDVOJBkT87Ro QaSmlLQXsOKF4iII1/fDVbjXJaY33hYqLm9X27TV X-Received: by 2002:a17:90b:5101:b0:34a:8c77:d37b with SMTP id 98e67ed59e1d1-352731799d0mr16280896a91.16.1768994861154; Wed, 21 Jan 2026 03:27:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Wed, 21 Jan 2026 16:57:29 +0530 X-Gm-Features: AZwV_Qi0HR0yssnBspapwYkFr7BPrWlSs3Gs8t1-nyk1m8rWI796eFmWOqbd4HU Message-ID: Subject: Re: Skipping schema changes in publication To: Dilip Kumar Cc: Amit Kapila , Shlok Kyal , 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 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 Shveta