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 1vpFoF-004T3A-2c for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Feb 2026 01:11:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vpFoD-008pfV-0M for pgsql-hackers@arkaria.postgresql.org; Mon, 09 Feb 2026 01:11:24 +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 1vpFoC-008pfM-22 for pgsql-hackers@lists.postgresql.org; Mon, 09 Feb 2026 01:11:24 +0000 Received: from mail-qt1-x82c.google.com ([2607:f8b0:4864:20::82c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vpFo9-00000001Cao-3k7T for pgsql-hackers@lists.postgresql.org; Mon, 09 Feb 2026 01:11:23 +0000 Received: by mail-qt1-x82c.google.com with SMTP id d75a77b69052e-50335b926c2so36907441cf.2 for ; Sun, 08 Feb 2026 17:11:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1770599480; cv=none; d=google.com; s=arc-20240605; b=ZU8h83GAmEwDDJ85iDQL9vRG6awGE+vRL4aZwAY5z2W+021x9mlhVd5ot7RY1d+cNo NNV/ZXbSb05/VFrvJiU3+EXC1lM74ojxfHG7c6S1mjqxTeoFl6o7SfX8Nu9aNsYdsB/4 IPwBV69QaZAdG4Bjtp3OSdHtk0vzQINCA+u5Y2p2IstvnbavA1OcLqSjxU3n6plbWLQJ dOqLCGhLZ5/QHocPHQWS96+bFLs0AXnTZkQfE0AHqKdscNKhcE8Wk10HxGx+Mm2FXeZz hzSKoQPixJ6yOQy9wlHQ+rxvQnKI5aphqXviLNyEu/K/JuLRJcamTBz7qHnz2M9Vmzlc wO4A== 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=qqBAK1gpWf0U4fv2EhaqZHsgr+g99CD+wtU1oa1nNd0=; fh=PhCEfW0HhlgvYzMPlRoMqef8bFlVFCZgTr7wezqLDlw=; b=RVIaMsQKDytl6Nue5uFTYOuAEBRfGvmEwaBYcm+1olqyD8dZ0FoT4zia2u+CppBXeE ddBjePJSXy1MBWVm8qwgMWxUlRIE1dBBarZIu1u8lLXKFuXm2L+vM8catjO6GjmLE9M9 1zInaz3WmwZS2q+E1HMHWQhIL2dbs/zXW6uAJQ9ITUWJ9D5V64z5rwiEvSquOPS6X5iG q2hDOP9Bh8/NDeRVN1AmCLBpzgO6djx3YKE3M1TQV/9Kd4fFLynwBe/y4CqOf6ogSJ37 WFxOA36BxEAt3st1NMRoCLrgpeVr75dbGYWbY59Vtr4XPirCzBam0NfRQCH4X8ufqtx/ NHWw==; 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=1770599480; x=1771204280; 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=qqBAK1gpWf0U4fv2EhaqZHsgr+g99CD+wtU1oa1nNd0=; b=MCwikLhSg67/pQ6S8SS0Kokqhe0VOBYZtHshl6dw029pRtT7ygEjuWvAsFToU5bjau QJcDyyVZsRsvPp9aVATgBtim/h/DzekwTx/jjamopag03Ajp4nfAGT/CK+yhRdcVaFHq WsSOVoLPWx8hWudhQlToDgv+PmPw/48qXMOlMoixMDFQbuJQGwtHx9hZJP89euqWxr45 f4N1fT7y/vvcvgoBJpGAoQ235o4ZNEXPRbUQnGLW+iGjlZUlOd9dbQY8mNhjaJHIXlIY JJZVJPHpuWQDeRLUBsVsuPzmepTq/gFywl00X/MIN+xsfFmuiyxQ913x/V6BD2yrqtlL Ms+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770599480; x=1771204280; 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=qqBAK1gpWf0U4fv2EhaqZHsgr+g99CD+wtU1oa1nNd0=; b=m4yUoKUDePngfjtzBDG1CULkI+qvLUv+AHguIl4eO9NB5Q5WNi8bzfKIuIaoY8knUe A0i+83GDOqA5+czSd+hCEyyUDD9hxN14dO4JFDC4AL6lZ12k4ekkhKegMWzWri9AdY29 aaBYaaVAWHGdyaEOPrlUpLe5gsbWzVHl3WddGAQJdwABZHit2NzXPEXVWI7uuVPo+4pZ Xv+pXHQ6bcD9hoardK4F2W3xrf+NDAaK2AKSEabwBNqQizj7Ig+zEXPrGUhEQc88Pg9m 4h/uXm+bo77FRoHL++zrFN9PxD8CCALq//Ih6NxB3k+cHWsMm/Kd8OYTV5G2AxrnXULX gGHQ== X-Forwarded-Encrypted: i=1; AJvYcCXwySPeI0HzSg9xXNH01KeFqlx8LxIyH365MbFG0XaK3aFUhyf1QldVmTYxI+KOrMWy7aAMyaQk1LOVJ7K5@lists.postgresql.org X-Gm-Message-State: AOJu0Yz9bFo8CCaiKkRQ4U1+yvH9lBgugMS9eh5Kx6McGiiGRcsxt9yy llTdwXWqpCUsK8qro7pKRREgJw585RNjN4eI73gtZVRkK1ADkMIshdQusq3NU48241CRkYSmsjC PGhM7aviHiUBqs3zkPX1XC3ExLIxbNgw= X-Gm-Gg: AZuq6aLXJnL7uAW14k98w9og+HAJWxFnu3VNEF51mDnjikMnBamRFHnWdILtC3OyCmV Kwm1FLuL11JwM57PCQIsDDX9OnRFR8ohaHrKhAjlJ7iUy+R5Icnf9MDHoJzuyCd8VBiH2tzsZSV FyCfQhFBjnvfRPCJaBs/YlKrH/MpUEB3XcQA2wICF26NePt1kU7koRTDf2E3IU7e1c0shIXK70p jdgJa5iMF6Frf8YQFzHqRQiVeWwWNSbMLSwBEdZFjsnqnikqIfQgbeYVwZKXWeFW9Fm85EfsWPs jYo6tzEakQK2mSx5d1sUJ5byhpWc/A== X-Received: by 2002:a05:622a:1a97:b0:505:e4ab:ce7 with SMTP id d75a77b69052e-5063986a744mr123046171cf.10.1770599479880; Sun, 08 Feb 2026 17:11:19 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Peter Smith Date: Mon, 9 Feb 2026 12:10:52 +1100 X-Gm-Features: AZwV_QgBWklxussZlBxoK8O-Of30FqhiUad9c9vjOFNVsfr-GR5KN0MUwjscMSY Message-ID: Subject: Re: Skipping schema changes in publication To: Amit Kapila 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 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 th= e > > > corresponding test in 101_test.pl file. > > > I have also merged the v40-0001 and v40-0002 patches to form v41-000= 1 > > > 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-lists= .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? Indeed, if the user wants ALL TABLES, but they want a row filter applied *only* for tab1, isn't this combination probably a good way to achieve that? e.g. "pub1: FOR ALL Tables EXCEPT (tab1) and pub2: FOR TABLE tab1 WHERE (c =3D=3D 99)". =3D=3D=3D=3D=3D=3D Kind Regards, Peter Smith. Fujitsu Australia