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 1vZ4ap-002iFc-0W for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Dec 2025 09:58:44 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vZ4Zo-00917l-2M for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Dec 2025 09:57:41 +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 1vZ4Zo-00917b-18 for pgsql-hackers@lists.postgresql.org; Fri, 26 Dec 2025 09:57:41 +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 1vZ4Zm-002uPD-07 for pgsql-hackers@lists.postgresql.org; Fri, 26 Dec 2025 09:57:40 +0000 Received: by mail-pj1-x1036.google.com with SMTP id 98e67ed59e1d1-34c718c5481so6946533a91.3 for ; Fri, 26 Dec 2025 01:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1766743056; x=1767347856; 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=3mOHpCz4V15sZKT/JLI1FHgvEvGiJErVMQ6yntsbs3E=; b=D6jC2TDNXiInegRnf+NuVpI8XLY9sX8rD2nEqjZcHkwSOv8HP/XKu0b1yG8NbRipYT l0c9xjYdl8/X6zTAHEuf4WWQBg3cLasOHHxVkTPdtBVz0b9ZRY9VyjmhGMdLaMXZReJd DXfoZccgamyTvDULerAk8qXpTmHW+2yWPcxn5JNVASCBveH8dkwtsqTumIJJkYgG1Z+9 Dc3oaTdIgNlgnMI7Sxzk6rh26OG3K4U2Piz27J3Ezd+lli6hEVpgfeGX3bzwu/TH1kBN W7YNRkiylsUsa/y0f+EBnCGF0QIXBRJyT27YvSZaRzWelQTKdAS2novshWd7HWgU82jW j7cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766743056; x=1767347856; 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=3mOHpCz4V15sZKT/JLI1FHgvEvGiJErVMQ6yntsbs3E=; b=Db9wx6SWi5rrBevq66Enx7lqciIwIGJd0XpviOC9DFRnc7cyPWUFdmMd8Dx7RXqPfb DF/kC+gSHQx5y1Hvmtxyv0JyKWXUpP1w8x9c2Svk5fZ9FY+XOZnO2N3srXGHR8FYHePH Stu+OScRW1gMnE4rqZC17K3scXrv/S42L1e9Ai5kfzxjnpDdm9tarMkOxAxHdCjSBWoq p+aOEphZjGJJXKxofO2jQ3gZLVtBnSNDguAfRPHcpi3kjjUCOepSDq8B+XhoJ23n2xq1 yff9zmTR6vKA0c+6Q3HyBEWIVxxpA6vMYFYS8/UY8Asic1Ja4qlVOvAQYUCi5MacrBiZ 5Anw== X-Forwarded-Encrypted: i=1; AJvYcCV33pPeNAJoE4tZMalHOaZ+topNaARiZbjzLqGmFq7RopT00ieT91RW1hoVrY2x4PHfIPitGYU3FM2HSdNZ@lists.postgresql.org X-Gm-Message-State: AOJu0Yxs3kh5fKSINoyD3YLeLk5m2assWpmEPvmR9Ei2UIdjipwaJ1rs cgtDoxGk8BQdvmPvTonvwMztHxOfqpcBJqdnQrkAq5KMytLwUHx7k+j8gQecDoQcHK8wn8xoAgj 1tEaAkdWeHs2pyGjJ9fZdG+sCOJPfvYk= X-Gm-Gg: AY/fxX5FhYGOjZo7JdFxg3XVRpkvQP+mN/0MOf0c4BMNjhzmQiLP3nSydezB8YDCEx1 Ftk6NKPkJ+Xmx28wbWwTWr8Tv50nk3FX2a1AoMKJQFMEO4zfuzYmRwY7hYjpiS83ut/vAeEa1Jg /1F61N6Rgh7xLrrRE6EHdqAu8UWTOTvD1fYdqUbuFB/QnKrlXc1L6LIkAOuRMka268gAyy0F5ek mo+Im4CHDVpWXelEGetfnoOoSmkzGV4tNCzTDV6b59P39ZIfb2gPk8YmOGp6uVkxwR+JhHggXsP /selfZcCarlhK079AetJRrM8D0Exv6NDxlyAFa2+ X-Google-Smtp-Source: AGHT+IHs4ErBvpFNpCSwwYdodJC8jMZ4pIhMMj9XSgh+U7oFqJt2fqBGozbG0ahkrxCoxxe9Pn5BY3qwOz2PLzqUPKw= X-Received: by 2002:a17:90b:35ca:b0:34a:8e4b:5b52 with SMTP id 98e67ed59e1d1-34e921371b7mr19388511a91.8.1766743055636; Fri, 26 Dec 2025 01:57:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Fri, 26 Dec 2025 15:27:22 +0530 X-Gm-Features: AQt7F2r5RK0v3iXxH2XvIX01cdGREg_r-jjfbYxd5rPvABpza4VzMSBbg2MN3hM Message-ID: Subject: Re: Skipping schema changes in publication To: Shlok Kyal Cc: Peter Smith , Amit Kapila , 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 23, 2025 at 12:03=E2=80=AFPM Shlok Kyal wrote: > > > I have addressed the remaining comments, did some cosmetic changes and > addressed the comment shared by Shveta in [2]. > [1]: https://www.postgresql.org/message-id/CAA4eK1+rnjBOvkiQC2r4LuTwuje65= 3iVPPAXcmJZXPpKvsNbOQ@mail.gmail.com > [2]: https://www.postgresql.org/message-id/CAJpy0uCf5tXvqyVS3GQzU9J5HdSLA= xX6Lxt1UKY4HJ8qnimCAw%40mail.gmail.com > Thank You for the patch. Please find a few comments: 1) GetTopMostAncestorInPublication(): + if (list_member_oid(aexceptpubids, puboid)) + { + list_free(aexceptpubids); + continue; + } We need to do 'list_free(apubids)' as well here. 2) GetTopMostAncestorInPublication(). Currently it has: if (list_member_oid(aexceptpubids, puboid)) ... if (list_member_oid(apubids, puboid)) ... else ...schema mapping check IMO more natural order of checks will be if (list_member_oid(apubids, puboid)) .. else if (list_member_oid(aexceptpubids, puboid)) ... else ...schema mapping check 3) +/* + * Return the list of relation OIDs excluded from a publication. + * This is only applicable for FOR ALL TABLES publications. + */ +List * +GetPublicationExcludedRelations(Oid pubid, PublicationPartOpt pub_partopt) a) Since now 'Relations' term means both tables and sequences, but here we mean only Tables, we can rename it to have 'Tables' rather than 'Relations' b) Similar to GetAllPublicationRelations which is for 'ALL Tables' pub, we can rename it to have 'All' So the name can be 'GetAllPublicationExcludedTables' to be more clear. Also we can move this function close to GetAllPublicationRelations as it is more related to that. 4) ObjectsInPublicationToOids() + case PUBLICATIONOBJ_EXCEPT_TABLE: + pubobj->pubtable->except =3D true; + *rels =3D lappend(*rels, pubobj->pubtable); + break; Let me know when this will be hit when we already have 'ObjectsInAllPublicationToOids' in place? 5) get_rel_sync_entry(): + level++; + GetRelationPublications(ancestor, NULL, &aexceptpubids); + + if (!list_member_oid(aexceptpubids, pub->oid)) + { + pub_relid =3D ancestor; + ancestor_level =3D level; + } + } Consider the following table structure: t1 has a partition p1, which in turn has a child partition child_part1. When publish_via_partition_root is set to true, any changes made to child_part1 are replicated through t1. If we add t1 to the EXCEPT list, get_rel_sync_entry() still marks p1 as an ancestor to publish changes or child_part1. Is it correct? 6) RelationBuildPublicationDesc() also needs some more analysis about getting and setting ancestor part for above case. 7) Currently the way we deal with the except table in pg_dump.c differs from how we deal with included-table. To explain the same, how about adding below comment in getPublications() just before we fetch except-list: We process EXCEPT TABLES here instead of in getPublicationTables(), and output them directly in dumpPublication(). This differs from the approach used in dumpPublicationTable() and dumpPublicationNamespace(). Following that approach would require dumping table additions later as ALTER PUBLICATION =E2=80=A6 ADD EXCEPT, wh= ich is currently not supported. thanks Shveta