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 1vvCBN-0080iq-1m for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Feb 2026 10:31:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vvCBM-005Zhm-0l for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Feb 2026 10:31:52 +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 1vvCBL-005Zhd-2p for pgsql-hackers@lists.postgresql.org; Wed, 25 Feb 2026 10:31:51 +0000 Received: from mail-pf1-x436.google.com ([2607:f8b0:4864:20::436]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vvCBI-00000001Cdt-41Xx for pgsql-hackers@lists.postgresql.org; Wed, 25 Feb 2026 10:31:51 +0000 Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-82491fbf02cso3666443b3a.1 for ; Wed, 25 Feb 2026 02:31:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1772015507; cv=none; d=google.com; s=arc-20240605; b=BwjY1oUTA6Tcpo2zWBu7pvPu7aDBgwI7wqtusaCg0bnnvJoWitumQbNY4/k6Z2ysav FSzrxR9W7fu/HUJJ4P934ECGGH6n14egIRUTEx7qGRPd7JW++BPkIgoPzOXEVmwQM6IF dcRC+u4McdMpPGCgC8UWBXKDx4porYu4Mb7vBkAIgH0fmuQcbkcN4UrYj/EnVzbVweQi Pmqyv4Q+8efq9AqpGek9Q9ZWW5fbFNXpgPHq34zYFI1sWdippxu29yUnN6wetqxqwWmI pHONH0U+pDpXzW2eXNzPLB+chKeQKeLy/ze6jWAlmcmuECmD3VJANzPpY1FYTw/xHaLS O9UA== 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=8CiENsvjm7YmKMoTvUfreLc1S/Co4iEXuGPTd91YYgs=; fh=aocY6HbfW1ZjMgOlzkj318Qpx7P2FVru8VTibTcagdk=; b=KaIy1iw6aqvSAyVVlK7hS5CsqFE5uA4itQK7QFCtYu1EslFGK1X+ty5CFi8vSwyUp9 6ItO0AJ92PF9kFJw+XowZkBXDZDmto6j6yUKBrAUeZEJRqc0pClv6JgGWRyaFXwJooG+ x/QqE+pEKbSH8MlyBF3PYlN89ZX26sFPuOTmFfBqFmU7x9SvaczZFhEacEGIC8NTPst+ ZSu+ReOklpwU9n8ZIRBO00mxZvEX3utbFCkb+ddL0GrCsHOepgQUxIROuyfCixYIzj72 wAct/likRV4cBpoC0RQ8NYaamiz085aYmCVmVSxYibSjQiKXy+XJS0byJuWhpQVKSVvD E5+w==; 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=1772015507; x=1772620307; 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=8CiENsvjm7YmKMoTvUfreLc1S/Co4iEXuGPTd91YYgs=; b=Vsg6Mj0gKoFZXBUVkCZ3N3Eb8yadYGtksJ03e18Z8/aeyDeUv4Q7sI9y8falevhUuz TVMX2k5sk8pXFj3ghdZ5ZoI8QNlvhTzbyjObJNyzCWHU756RY5aJoz1UVOvHrghEZ5Z1 RC3AHMcKwnLf/xfFMUCR6hBYpbmIRXiowE+1b+vgYJ2M/FYFhGabNByLIK0oydzxj2x5 mhudEOZrfZWX0EMRs30c1SAGJonnQZKi7M2aagwSJ8N+22O4/nYHINP9k1LwIPKQdL8S 92KUVoJT/IyBGShSSSbhkWLNifx5utIfFwVqKIe51BfnDShN23FPeBSkd1THj0X5VO+k Zj9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772015507; x=1772620307; 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=8CiENsvjm7YmKMoTvUfreLc1S/Co4iEXuGPTd91YYgs=; b=VP6wlH/xosG+SEcYKHResjueAzJQpEJQ6VlgR4/C36HR2eKqmDrUnUUYGuOa6Hrjh0 18GtTN9uIsi7Vo/FdDBT2eIrYaBkSHksP4k7JYOF0/ybALBg7L4ZEpyKriMEyFtwcGHz h6a1e6xIPEQyTcFn9OFHpv2D24AgxpQAP8RMSIUtTD4bUOh/vZAhUbCO3p2HynA4ivZV 7kc8yOgv9h9D9RUya70zC7uj+8e5itKDl9U4JGKWuaPMPrGa6f90b39pxBdLQN87xnRQ 1ceNwchvtjJN4DSkwFtROJPBzswcjH+6jVijKyPyq7lhhxW+zQSinfvUouqsWGN2fTE5 WriQ== X-Forwarded-Encrypted: i=1; AJvYcCUIbQ91KevXsixoDB5xGiz2gdr5ikiAim/d91/ItZCpaMjMC2obXbJA+bsPVd4+kH5UCr5r8YMU28LtGIUc@lists.postgresql.org X-Gm-Message-State: AOJu0Yx/8PfvPodmnA48CWlzTH3BNsf6QmzHLR6CCnEslXtXzxc1H8QA HJZ/xh/sIph3LIifUaRDAWpXQft91R78yrK8WrwJJ6/HTIyWwLBh2ORaezI+qG8xJJ3m8k+tv/e 8cXIUtuLNzwPFKnZa8zb8rvlzscbdb8I= X-Gm-Gg: ATEYQzxiYl532ag9yvjTBh4jpb+QeEkUljufG2bE1JLiKimpAKDtBOq2C/daO8d/nRs Da2mU1S65gFeUAeNRsPjjrjgDQVL8j84DlYmV14LpFOmD6ja8u24SUaofp/B1r0jTEp9oUiFHD7 vuP0h8Rc8M3cSvlYpsZcznb3ORr7HNoXsiqTNmI3aOUHqPyNP9kshAx7iSVE0AzqreZd/U6hB8X IwsLznwb1hXApbZ8TGR6TRlUG7sQmgYGCz8Wc2r32MZ0Cvxwp9VX97SRsJXHkk6Gk126CMVfAZR 9cXmvp3+hLzKaFhxKvy2isl7IfEOuiOmHibCwk78kFxx4hl1XDLmsA== X-Received: by 2002:a05:6a21:7703:b0:393:e2e3:5de0 with SMTP id adf61e73a8af0-3959f2c22ffmr2192678637.27.1772015507310; Wed, 25 Feb 2026 02:31:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Wed, 25 Feb 2026 16:01:34 +0530 X-Gm-Features: AaiRm53pWFd9zs6YBcVHONOYgwEP0x_A6QifCx0mcDxsJap3m5AR_uiuC82Qgys Message-ID: Subject: Re: Skipping schema changes in publication To: Amit Kapila Cc: Shlok Kyal , Ashutosh Sharma , vignesh C , "David G. Johnston" , Dilip Kumar , Peter Smith , "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 Mon, Feb 23, 2026 at 4:46=E2=80=AFPM Amit Kapila wrote: > > On Mon, Feb 23, 2026 at 11:37=E2=80=AFAM Shlok Kyal wrote: > > > > I have also modified the error message as suggested by Shveta in [2]. > > Attached the latest v48 patch. > > > > I see that the second patch (0002) brings complexity in the patch to > deal with following points: (a) The first complexity is if one of the > partitions is specified then how to compute the initial set of > relations to copy when pubviaroot is true. This is complex because we > need to exclude the partitions specified. (b) The other complexity is > combining Except list containing partitions and other publications > specifying partitions or partitioned tables both during replication > and probably during initial sync. > > I think it will be better if for the first version, we allow only root > partitioned table to be specified in the Except Table list. This would > mean that if the user tries to attach that root partition table to > another root then we should give an error. If we go via this route, it > will be important to allow users to remove some tables from the Except > list, so we can provide Alter Publication Set Except Table > (table_names). > > I think excluding specific partitions may also have some use cases but > adding additional complexity and maintenance effort is worth, if there > is a real field demand for such a feature. > > Thoughts? > I fully agree. The additional complexity does not appear to be worth the value right now, unless we receive meaningful user feedback that justifies implementing it. Thanks Vignesh for the patch supporting this approach. Please find a few comments on v49-001: 1) + in EXCEPT TABLE. Doing so excludes the root table= and + all of its partitions from replication, regardless of the value of + publish_via_partition_root. The optional + * has no effect for partitioned tables. + a) I feel it is not needed to mention 'regardless of publish_via_partition_root' as generally that never decides what is included and what is not. Same is the case here. b) We shall mention both ONLY and *. Infact it is 'ONLY' which has no effect. * is the default in this case. But still to make it a more generic statement, we shall mention both for partitioned tables. 2) + + Create a publication that publishes all sequences for synchronization, = and + all changes in all tables except users and + departments: + +CREATE PUBLICATION all_sequences_tables_except FOR ALL SEQUENCES, ALL TABLES EXCEPT (users, departments); If I run the command given in example, it asserts. TRAP: failed Assert("!stmt->for_all_sequences"), File: "publicationcmds.c", Line: 942, PID: 70620 postgres: shveta postgres [local] CREATE PUBLICATION(ExceptionalCondition+0xbb)[0x611280ed8c48] 3) -check_publication_add_relation(Relation targetrel) +check_publication_add_relation(Relation targetrel, PublicationRelInfo *pri= ) We can avoid passing 'targetrel' now. PublicationRelInfo has that info insi= de. 4) postgres=3D# create publication pub2 for all tables except (tab_part_1); ERROR: partition "tab_part_1" cannot be excluded using EXCEPT TABLE Other errors are in active voice (eg: cannot use system column \"%s\" in publication column list, cannot use publication EXCEPT clause for relation \"%s\). Shall we also keep this the same way? I think we can mimic the error for tmp and unlogged tables which is: postgres=3D# create publication pub2 for all tables except (tmp1); ERROR: cannot use publication EXCEPT clause for relation "tmp1" DETAIL: This operation is not supported for temporary tables. We can convert concerned one to: postgres=3D# create publication pub2 for all tables except (tab_part_1); ERROR: cannot use publication EXCEPT clause for partition "tab_part_1" DETAIL: This operation is not supported for individual partitions. 5) + if (pub->alltables && pri->except && targetrel->rd_rel->relispartition) + ereport(ERROR, + errmsg("partition \"%s\" cannot be excluded using EXCEPT TABLE", + RelationGetRelationName(targetrel))); + + check_publication_add_relation(targetrel, pri); I feel we can push the partition check and error to check_publication_add_relation() itself. If we do so, we can retain the exactly same errormsg for parition case as well which is: errormsg =3D gettext_noop("cannot use publication EXCEPT clause for relation \"%s\""); And we can just change DETAIL as suggested in pt 4. 6) +++ b/src/backend/catalog/pg_subscription.c -/* - * Add a comma-separated list of publication names to the 'dest' string. - */ -void -GetPublicationsStr(List *publications, StringInfo dest, bool quote_literal= ) -{ Do we still need to move GetPublicationsStr() to logical.c? I see the only extra call is now in pgoutput.c which already includes catalog/pg_subscription.h ~~ Reviewing further. thanks Shveta