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 1vpJwc-005fd5-1q for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Feb 2026 05:36:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vpJwb-009Hh9-1V for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Feb 2026 05:36:21 +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 1vpJwb-009Hh0-06 for pgsql-hackers@lists.postgresql.org; Mon, 09 Feb 2026 05:36:20 +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 1vpJwY-00000001EB3-3E8n for pgsql-hackers@lists.postgresql.org; Mon, 09 Feb 2026 05:36:19 +0000 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-385b5174f54so28181871fa.3 for ; Sun, 08 Feb 2026 21:36:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770615375; cv=none; d=google.com; s=arc-20240605; b=B8BwpOSeM9m9E9zaU513oscs+ipdlTHaMQ+I07qJshwflHwPWoXlg8IpSdmMy2p4K2 tsuuN5X2sRQ7t8v6isarjR3S4gXcxsFcb0U0+8bb6vbDLdOMz7bkd3xBkRplNR1symrq ZONapS+MVr6eyjw2GmnJuN38hTXDZaT0TKYqpN6m9O5t+Xe9tjy+e49welmeLtidPFUR 2PFYfYJggf3fw69PSWZDBDw+xxGnh93lWRVZneFaiN3y96cl6xvTSCnd45tw0Sgonknz sJf1ZR4aG8dMbEro3iDzUvfq4Gm+8FTMiVZI0mVOtwdqFqnCuTLLO7iNXdS4YRgCfJBo sLCA== 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=48KdYFiPGLgh39CpqcOnLNaDtwS7E+m/L9d1GmIxH0g=; fh=nIQ30VxSnkEIGAMii0JOGsjgfLFrQuEigjvax7nZcz0=; b=QWEiYnDolnBezcLOpbIbmk7Tm/TzkbvV+31JtBTEAXHq0Ghw3bZg6ovKN4+uXsMFOv 4Mj2/GIwWbFJnr84W4pOMd0u/EN1T72FDRMxMKJHuq4HkCtqHp0lK/zS0lRQe6rq0xND p1Y1rJFQGotPcFh8+T4grcC545/LedYaSDyYC8Md2qDw/arTfum1EUFMwSvXcX6xuo0D VGxdqvBf/sm8FrhNOmbeOHUuPuDrG8GOY40HOkDjU7WctVfxPAxNu9rOMplFiURHFlHk Dby/JrK8dTDNYq7OnH9xiiQV3rjG9+WbM15T2/j1qH/0QGdUeL0yocx867HHGrKcCMQO /nHQ==; 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=1770615375; x=1771220175; 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=48KdYFiPGLgh39CpqcOnLNaDtwS7E+m/L9d1GmIxH0g=; b=K2INnd4kY75JqKVM5YHWZo1rnby6taKackwTVP4xR8Mqs7RB0m5rcb3bLBedrw8G+F pN7EtBXaYYMG+Itkn6jBOJiVyLlFoIto2oGaHMA715WKt2v+lo58lQtbLx5/5n+/c2b0 mc/aciB+qPMQ3TRxDJfiwPRdHe1DAAPHI4OY0GTJsdndeXou1aKCy5FRl81vRR6juEvI 18Q5TKyTJ7hUzZhAU9JO9LuN1oXyfxyVp0ZHuvaCjM51j19t8Skn4SIFChl7dRUlL7TO jUi/q73f2IPfmO/xvR4PeQqdIrBb1RWvPvOZ5H7en/OzQaPa47SxT67fdV5+/HNGf4uF CYZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770615375; x=1771220175; 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=48KdYFiPGLgh39CpqcOnLNaDtwS7E+m/L9d1GmIxH0g=; b=jTyArE19SC22jdTpDMoOISgwANaY7kX4AWo/OJjoiJ7PPNjOEJR4vNQWpccLqLRkip AbcesrzENyFnSsY5M/6rYOnkbtVX6JzGTlxj9V1UNdnnPQocO2g03Mj0LxHQqv3O/l30 2RLMEJQ3tdO3ZrrI+1XJyU3QoLVgTMLVm125rEPkCYfFDPUuGbm70Jb+/lkSVX/bmDZ+ lUHu4nJUv82ZvX94E1r4Dx9gFGs/wtoCILbTgZ2nkMAfCmxw8oaX6y1aYzXc+JuXnXdn MP/YArgLhIKwG717uDZTDHKgD3baplj9GZPp2yQZqAw+7OGB+ZhiMykNZ9r7rq9Ii3qy vfHg== X-Forwarded-Encrypted: i=1; AJvYcCWi8pZx3Os0zAEaGNG5JumUd8DHIQXMLxXoIQHDNwMbnvq3GSQ/3sfg0b6Iq142Nm3zT8NE+5na3URvkNFY@lists.postgresql.org X-Gm-Message-State: AOJu0YwwQmyocI+oUkx4LLicUN58Pr+oOfYcH3mG0e+5MNmQMBaTwZpq b6r8VGZKFhquGKNPhqDH0Hw41SDlR5kvSE7Oxkjv/Me0pYrtbmxFLXK4De5pQZC+f5Rpt9DUW8S Kr7w07aoXbpPPeYgHms99vHC9ok8Jo8Y= X-Gm-Gg: AZuq6aKIS5kHnbJCf38X3WpcfEF8iaWWLI1mn/jNkZ0o900nyN5TrD8Ieovdv6KCQGS RK2Y03dJiRhdTjDbjN+if1ElJjqOfHb8LZECdzcChLtg3yKqiNPb2GFoSNnO82q5rIEWl0K6rkh OdunYvSvI1fMkhbk/K6q0yZwcrTuLzRDD+iX2zZoZ2lOFjUMYFWabOe3MkhDlQ+RX5wDSzcKYPE Z1A6PjOXw5uknPyaI7KPSQDiUhguMCPnqAsTFnTTUSzT7GyNtzc5dplZyxFL6E+hKycLz09srUL MGzc/p/+PHdUEhbPOEY5Jw7e5PsD X-Received: by 2002:a2e:be1b:0:b0:385:9b50:91a8 with SMTP id 38308e7fff4ca-386b4efd8b2mr28951291fa.15.1770615374835; Sun, 08 Feb 2026 21:36:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Mon, 9 Feb 2026 11:06:03 +0530 X-Gm-Features: AZwV_QhNLFnBpvXsYeOVE9gpCQUDjoKA_aeqU6LsQozZsMxOQ5JDdT9ixzdxAgE Message-ID: Subject: Re: Skipping schema changes in publication To: Peter Smith Cc: shveta malik , Shlok Kyal , vignesh C , Dilip Kumar , "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 9, 2026 at 6:41=E2=80=AFAM Peter Smith = wrote: > > On Sun, Feb 8, 2026 at 9:21=E2=80=AFPM Amit Kapila wrote: > > > > On Fri, Feb 6, 2026 at 3:54=E2=80=AFPM shveta malik wrote: > > > > > > On Thu, Feb 5, 2026 at 10:59=E2=80=AFAM Shlok Kyal wrote: > > > > > > > > I have added the fix of the same in the latest v41 patch and added = the > > > > corresponding test in 101_test.pl file. > > > > I have also merged the v40-0001 and v40-0002 patches to form v41-0= 001 > > > > patch and v41-0002 has the extended tests. > > > > > > > > > > Thank You for the patched Shlok. While testing I found a case where > > > table-sync and incremental-sync are not replicating same set of > > > tables. > > > > > > I have attached the test-case and results in DifferentPubViaRoot.txt > > > > > > The problem happens when we have a subscriber subscribing to multiple > > > pubs with different EXCEPT and different PUBLISH_VIA_PARTITION_ROOT > > > value. Example: > > > > > > CREATE PUBLICATION pub1 for ALL TABLES EXCEPT table (tab_part_1_p1, > > > tab_part_2_p2) WITH (PUBLISH_VIA_PARTITION_ROOT=3Dtrue); > > > CREATE PUBLICATION pub2 for ALL TABLES EXCEPT table (tab_part_2) WITH > > > (PUBLISH_VIA_PARTITION_ROOT=3Dfalse); > > > > > > We need to decide the behaviour of such a case for Apporach1. > > > > > > > It is better to disallow such combinations where combining > > publications could lead to contradictory behavior. For example, pub1: > > FOR ALL Tables EXCEPT (tab1) and pub2: FOR TABLE tab1. Now, combining > > pub1 and pub2 via subscription should result in an ERROR. We have > > similar restrictions for column lists. See section: "Warning: > > Combining Column Lists from Multiple Publications" in docs [1]. Does > > that sound reasonable to you? > > > > [1] - https://www.postgresql.org/docs/devel/logical-replication-col-lis= ts.html > > > > Hi Amit. > > I understand there can be some tricky scenarios where partitions are > involved, but I was not sure why "pub1: FOR ALL Tables EXCEPT (tab1) > and pub2: FOR TABLE tab1" is an example of contradictory behaviour. > > Consider if the publisher has 3 tables tab1,tab2,tab3: > Here, "pub1: FOR ALL Tables EXCEPT (tab1)" is like a shorthand for > saying "pub1: FOR TABLE tab2,tab3" > So what's wrong for the subscriber to combine pub1 and pub2 in this case? > It is because one of the publications (pub2) indicates to include a particular table tab1 and the other one (pub1) to exclude the same table. And things become much more complex when the Except list contains partitions as shown in Shveta's example. So, I think it makes sense to keep things simple at least for the first version, we can consider to uplift this restriction if we see some use cases from the field. --=20 With Regards, Amit Kapila.