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 1vsEd2-00CEHB-0o for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Feb 2026 06:32:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vsEcz-008aCZ-1V for pgsql-hackers@arkaria.postgresql.org; Tue, 17 Feb 2026 06:32:09 +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 1vsEcz-008aCN-0U for pgsql-hackers@lists.postgresql.org; Tue, 17 Feb 2026 06:32:09 +0000 Received: from mail-pg1-x52d.google.com ([2607:f8b0:4864:20::52d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vsEcx-000000019L4-1lLh for pgsql-hackers@lists.postgresql.org; Tue, 17 Feb 2026 06:32:09 +0000 Received: by mail-pg1-x52d.google.com with SMTP id 41be03b00d2f7-c6dd5b01e14so1310720a12.0 for ; Mon, 16 Feb 2026 22:32:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771309925; cv=none; d=google.com; s=arc-20240605; b=XXsrBT7hktWSzbrlr9xqQ0+4BfMs7WCkZElSxFj30jAkM7HYihndv6SzgMp4K9qp93 E8wesy3Q2ntMCW/lnsqIDxETLkrjPikULx8x0RSycJuDUQvXjQrVCYzsUk4RezuCdeQY XZGHUOEk7IefpZ4P+E2UjgeXfXAXOUR7hbKRBGhLYPcyhwly70Z/UYExhTnRyutGowpj cIIAytrp4/e6/WR2tHnmSWw4K0+QtCygjsX0jQsxoT//fX3z+1p930AHbmNTiV5pTljD X79zKv1ShjIpvD2Hqwkr9qKF6uEykRcTTFjn+Rh0VSYMMxmkU0JgveFBk8laYAwGIkFC Cw0A== 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=XOBG9u/fhsfGLfa3Pm63BM0ONZxVxP5dI9ZDSq9FxKI=; fh=VquJm0CPG77N87ARqP5yAqSslH0gUd1e/zf5nB9+GB0=; b=fPDZXjumPQgksZy1W283+G3h/bI4QKCzqmHKZcB4WCoC4Z5i+bcbQjNjI6GsyknVFE 1VnMzerq20akRSvBm1pc0Me3XaKiXSF7HqMmzeRnClQ/PQuPwmhg5fxWyGaeUjV8rUE0 2ngsHjelbq0X6Z/lYsUZXDCwLooH+yfbvuPhXmc9le4FEpAOIY82VJqxBtS3Ptjdhpbc nVunPEMs7YznXNw7SSJn+OyVs/X3N670MNWGvUVlfSZb5tdGDDhf/SjNI/vflGsuU9fU 844sy0HEnS3ZC6hlld+DVGGy0RF+NqjChiUHT5MU54pH5JqUZ8DMnLgIPsPzgNr0AJK/ zJnQ==; 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=1771309925; x=1771914725; 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=XOBG9u/fhsfGLfa3Pm63BM0ONZxVxP5dI9ZDSq9FxKI=; b=Xu0Z9COGghK2aOuwhUWi9cdPzK8LImsZyjmt56hsOowH9bkh+BOnss1uh7RcaVDsYt 6Wr1sEbnQfor9IP9jVtTA/LJMIROKKPRCi0kwEiKPG4pjK8n7GoNg1Ixtu8lSvrkmJcf +0qthbtEV7HRJPq1YMUB2H+dX6fEOgV+iFn6MH9zNyZIWSkBk33rlNx19+wWqUbbuu7i bG2b9hobkTDY1ROqKYAaGHt6aQS6rfFq1LICcG34cr97i2DaQI3CooXkBidljR+zrqeU BibM/+cKmuWP0+yCYl/dgVYuQVI8D3r6W2ghb/g+oGyEQSf8b9RSu0poIfFCphf9b8Kx r9DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771309925; x=1771914725; 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=XOBG9u/fhsfGLfa3Pm63BM0ONZxVxP5dI9ZDSq9FxKI=; b=skAp8LZs9C8k4Cn4KxQRdgsD99ZcDNSApjhGJXFhd2uWZaWS60n1ZQ2E5ICPUOCxtM e0h4z7R+VM6pydX7bALInomPWpXVfhfVZAFDxQbf4FbnniNsYpCfWq5vpBXGIa/0UbZF kn3ZadV4vN5USum1h3bdDyXyGvQh9wfR/uDHx7idvgECNoJSBdINCDdsLxIGUdGkJH0P eeyaYY8fSNtgHXDyggBtAl5LVUi2wuL6SfQR6Djj19kg0s7SWn8RepwJ2AM6zg/WWxoM 5suGnYMVjLOKaU83wlenY5a5dEwZusiKYiZmzwP898hUUOeIwtINDqGeDaej0XD0ZnA0 CkiQ== X-Forwarded-Encrypted: i=1; AJvYcCXSs+bZN8EP+FZGq/AFNx4QNR0hK3nRmHLZ5DzOfaqiTOaEVSRkC1WQeiO4KqkZSj1PWgG+3SKDF7mBqGZv@lists.postgresql.org X-Gm-Message-State: AOJu0Yz852ufKwC6Q2Sx1cWyuYGZ5KhiNd6VHRIvKxPZ6B4uqzcsSIwD 6Y14I9C9DnpL3YbUVk/75f3Q25TvxeOTA7O61T84uM1HlW7ziSUjyvEhnJz1dM7rnWvU9F9KEl8 pllr05X0x0at8an5+E3Ly8B5mZifdIBU= X-Gm-Gg: AZuq6aIjbHeetftLTHcT2325+l4x8t64nZxVR/4Q9ZjxAWALDy1ZCWO36BSHfCme5g4 MI1myN+sgch1wjbclDFPlZbEYFl/fVLHHbeBHiYCL2ndlDf5nLYZFyFa/iHZmNC6/LhDz7M7v0O juGNLQ1HvyYiI6vI+CNWU7Uv88/7+1z+xuwNPynO9+zswnHp+J0+0Ve+uC12ZTxSHYaLx8cj8qa BYJegdV1vwbsPb7qLanxKDIBF4wFEcmbEdZTo20ynczcLAY+azlGF++uacj9OLIS5hUglqmpa8n jU+Q8b4SQ1AWgahoKR4I1cEpDz4GsOZibtVgWJaX2/jDyKg4u7yQRg== X-Received: by 2002:a17:90b:524b:b0:356:7b41:d348 with SMTP id 98e67ed59e1d1-356aad5f21emr12487815a91.20.1771309925329; Mon, 16 Feb 2026 22:32:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Tue, 17 Feb 2026 12:01:53 +0530 X-Gm-Features: AaiRm50tVynEBzxhY1ad6ZB4BVgGhGcx-srzan7UDQoMS9uHIvAWI-CXrpRhY9Y Message-ID: Subject: Re: Skipping schema changes in publication To: vignesh C Cc: "David G. Johnston" , Dilip Kumar , Shlok Kyal , Amit Kapila , 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 Tue, Feb 17, 2026 at 11:13=E2=80=AFAM vignesh C wr= ote: > > Thanks for the comments. The attached v45 version patch has the > changes for the same. > Thanks Vignesh, please find a few comments from v44 itself. Please ignore if already addressed. Will switch to v45 now. 1) publication_has_any_exception: + ScanKeyInit(&skey, + Anum_pg_publication_rel_prpubid, + BTEqualStrategyNumber, F_OIDEQ, + ObjectIdGetDatum(pubid)); + + scan =3D systable_beginscan(pubRel, + PublicationRelPrrelidPrpubidIndexId, + true, NULL, 1, &skey); PublicationRelPrrelidPrpubidIndexId is index on relid and pubid, I don't think it will be used in this case where we have only pubid key. Shall we use PublicationRelPrpubidIndexId instead? 2) +/* + * is_relid_published_explicitly + * + * Checks if the given relation OID is explicitly part of the publication. + * This corresponds to the 'FOR TABLE' syntax. + */ +static bool +is_relid_published_explicitly(Oid relid, Oid pubid) +{ + /* + * Search the syscache for pg_publication_rel using the (relid, pubid) + * index. + */ + return SearchSysCacheExists2(PUBLICATIONRELMAP, + ObjectIdGetDatum(relid), + ObjectIdGetDatum(pubid)); +} How are we ensuring that it is not fetching the one with except-flag as true? Shall we assert when pub is all-tables to rule out that case/mistake? Or if we code-flow is expected to come to this function even for 'all-tables' pub (it appears to me t by looking at the caller), we shall return in such a case instead of Assert. 3) Shall we rename these: 'is_relid_published_as_except' as 'is_relid_excepted'. 'is_relid_published_as_except_with_ancestors' as 'is_relid_or_ancestor_exce= pted' These will be to match tones of: is_schema_published is_relid_published_explicitly I feel even for 'is_relid_published_explicitly', we can simply say 'is_relid_published'. Comments (and assert/checks) can explain that it is for FOR-TABLE pub. 4) + List *except_leaves =3D NIL; + List *allowed_leaves =3D NIL; Similar to allowed_leaves, shall we have excepted_leaves instead of except_leaves? 5) pg_get_publication_effective_tables(): + + /* + * Check whether the table itself or its schema is + * included in this publication. + */ + if (is_relid_published_explicitly(curr_relid, pubid) || + is_schema_published(get_rel_namespace(curr_relid), pubid)) + { + allowed_leaves =3D lappend_oid(allowed_leaves, curr_relid); + } + else + { + List *ancestors =3D get_partition_ancestors(curr_relid); + + /* + * Check whether any ancestor, or its schema, is + * included in this publication. + */ + foreach_oid(anc_oid, ancestors) + { + if (is_relid_published_explicitly(anc_oid, pubid) || + is_schema_published(get_rel_namespace(anc_oid), pubid)) + allowed_leaves =3D lappend_oid(allowed_leaves, curr_relid); + } + } Do you think we can convert this code part to is_relid_or_ancestor_published(), similar to is_relid_published_as_except_with_ancestors()? is_relid_or_ancestor_published() can check both pg_publication_rel and pg_publication_namespace. I do not see individual use-case scenarios for is_relid_published_explicitly() and is_schema_published() and thus it is better to club these in one function. So at the end we will be left with 2 such functions: is_relid_or_ancestor_published is_relid_or_ancestor_excepted/excluded (choose the name based on others comments too) thanks Shveta