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 1vtPuh-0065Eu-0q for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Feb 2026 12:47:19 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vtPue-007nQ7-2H for pgsql-hackers@arkaria.postgresql.org; Fri, 20 Feb 2026 12:47:16 +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 1vtPue-007nPz-0v for pgsql-hackers@lists.postgresql.org; Fri, 20 Feb 2026 12:47:16 +0000 Received: from mail-dy1-x1329.google.com ([2607:f8b0:4864:20::1329]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1vtPub-00000000Nfu-0pKH for pgsql-hackers@lists.postgresql.org; Fri, 20 Feb 2026 12:47:16 +0000 Received: by mail-dy1-x1329.google.com with SMTP id 5a478bee46e88-2baa098ffc6so1869740eec.0 for ; Fri, 20 Feb 2026 04:47:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771591631; cv=none; d=google.com; s=arc-20240605; b=bZW8MF6YgHMGIemQjMv9xdu1l903B1pjTeBodN7O0Kd7p1XgC0eN0gwg3ia59c08zl QrddCQaQ8HskfDhsU0cOWImO1bCTJ0fK5RVtVOOvcW2KFjMGrKNx3dGSCalYkj7Sl9pb v4/U4qPlrxcWlkHYAlzxsoU7GA8OHQKOpCD0wUPi+E3V8o4UfbzZQhb+MtmV9zxvz2ql HqoXKXrtYdaKYOo0578PAVP314x2Mr2MoF6JyV+cn4BGrI4l/mxFyon4uosTN3/2dSp5 cvWz9ddkSxsjygzNe9DiQm1svg4S9fuqwia1itaAjAmANsUToGTDq63S9LhUAXjKpc8g E8/Q== 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=CRaex20DtqyQHMg8+qnCFAR/mCPZKsd+GkiKeqFlXFI=; fh=sivkzybb0CPOrHh2rEMXZnIOzmUGPUz7jFpG2mYIUpE=; b=DIjlKA+ZvCkfDUE73ojKTRROxoefNLu8IaJjTdDQ0KXPpHNKB56gqJZxl//B40+asg AQtrhuvoNI242IcSxoRAcwgBQO0vuodhI4+gpkKz33zH1rIppkOycjS7pKo81eDD7y9K me1pRWDytV83Pe7pRt3VEfvO1cIc/v2MPurjPyepxWS6HBAYwJ0JVV+E1VnyfpD1oV/S XEykKzmRw5en5Wvj/7zCg54lcTv+IfUAJwJvl46McSFDfiCAJQT9CZO5pab1T6nuyFwO OhMsd60zuQG62VMJFEd2OadSiCRBnBGNeWc7cUu9zyIKW3f1eJuT26fQDyCHmwMPMJlT MLoA==; 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=1771591631; x=1772196431; 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=CRaex20DtqyQHMg8+qnCFAR/mCPZKsd+GkiKeqFlXFI=; b=iQtyZz3ImpQzPIOvMKAPTsRw5xX2gvn1Em9WtGIEqn8fTswSavQnFzascfPOeIOOuh afYf/UKlo4DPO1Rm3xTPWLi2vY+j4Ye+76y7M+u/GpHMSO+BL1Z9IghNRQNQN3A7JDyx FmewbxY4MOy7NQaYg0/LN7WQqhJCYAfYex6tzER2AQVY02IIDu5aqZLhfJ198P5dNEgo VQPfyfbWi9R8etWM0PEaxQuHn3mJD5F5OasLG8lhpLjXwUOMOts0j/aune7QCVJ/J/Sw WsX9dsZd0maz996T17i8bhtVXCzsVZPDW3gVK8o4BSRdp+nS6sl3j0sNO99d8O2r2ybt bHAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771591631; x=1772196431; 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=CRaex20DtqyQHMg8+qnCFAR/mCPZKsd+GkiKeqFlXFI=; b=W5V6+RiIa3Jzh3vPTirLIe96Kh5MBPQ48yv59LC/II/GhDXqzrNY5lktA5jcLOL5Hc h1/1Hiv1C5hATwvSWpxm18cT+CZYyCRN5tHJpqeXvgG9X/aY8t+556qnZSe10/DKMZ2o kdmIyjHRN164tpmbGJykumS3LJ3jkfasweWBY1oxqnjui2mkKNNXuAbIg2Qg++yglpSz DsCW+s74Hose9Gg0lIY472dyuxt6WBdD2YdJA30ekDOgBxLAzfAFHpshDPh7GfKKQs9I v8qLz50LY6lPxC8wFdP3+3ugtubMloxK9UURXpS+/4BeY/oNYWQ3tiBrz6T/kHnY4F9c GVNQ== X-Forwarded-Encrypted: i=1; AJvYcCVxLg1xwmN+Q6ZRz0wUkMEOOzkqGBZgam3xU2ThqT1eZpR1GasLFQr3WRYU1WD/fto/5E/xPTadXVvBHl1J@lists.postgresql.org X-Gm-Message-State: AOJu0YyzDE0I7FzwJmm767ovyxaS8XmhdlqullGT10mc3mm9fiSTzybS CFhJl/IOWHia2PQThfvSNMQw5miWmuiyEwdNbuwCZxi4qCTCyaJC6ioLJfJ60nQ6xFLmn+bX+uE gZIE10hLvZDS+ssCpBYiPzx3f/5eIB80= X-Gm-Gg: AZuq6aIBXM8Etp6m+TOOu270W4C6mdG9eMJBKvCbVbmF3k9DL7I1TUkSr/JwrOKadYS PpuT3I1DzIzpqY/Z/zJLYfJFlFuUmxihYl9Yze2UZth3N5Hk35St1fjsbQjmNnTJArA6miShqMu lQIzPpQUxrwi4Vgh/iEhMDdMi/5FzsDWXIzJG+oYPSVCCRSNqhQjos3i51C+M3zc9WWOsKp1hMF 4/3jtBKRIuklBT4kVffD027ZJvRM+SKp5rwxycGO9coA11I5r9jQnBDzMzPc9y+D77WR6sqa1Zz Mmetg+s= X-Received: by 2002:a05:7301:9c84:b0:2b7:f28d:c898 with SMTP id 5a478bee46e88-2bd7327f9ddmr591298eec.0.1771591631290; Fri, 20 Feb 2026 04:47:11 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ashutosh Sharma Date: Fri, 20 Feb 2026 18:16:53 +0530 X-Gm-Features: AaiRm531YTPP0S_WbMeM6eHhdMfegSE7vn0OUCugj2UogZui-hjPxRGL-gylkjQ Message-ID: Subject: Re: Skipping schema changes in publication To: vignesh C Cc: Amit Kapila , Shlok Kyal , shveta malik , "David G. Johnston" , Dilip Kumar , Peter Smith , "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 Hi, On Fri, Feb 20, 2026 at 2:08=E2=80=AFPM vignesh C wro= te: > > On Thu, 19 Feb 2026 at 16:06, Amit Kapila wrote= : > > > > On Thu, Feb 19, 2026 at 10:13=E2=80=AFAM Shlok Kyal wrote: > > > > > > Thanks for reviewing the patch. I have addressed the remaining > > > comments in the v46 patch.. > > > > > > > Can we think of some ideas to split this patch? One possibility is > > that in the first patch we give an ERROR, if a non-root partitioned > > table is present in EXCEPT Clause. I see that a lot of code is written > > to handle partitions in EXCEPT clause. I feel such a split will make > > code easier to review and validate. > > Split it accordingly. > > > Few other comments: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 1. > > if (stmt->for_all_tables) > > { > > + /* Process EXCEPT table list */ > > + if (relations !=3D NIL) > > + { > > + Assert(rels !=3D NIL); > > + PublicationAddTables(puboid, rels, true, NULL); > > + } > > + > > /* > > * Invalidate relcache so that publication info is rebuilt. Sequences > > * publication doesn't require invalidation, as replica identity > > CacheInvalidateRelcacheAll(); > > > > Here, the relations listed in the except table list will be > > invalidated twice, once inside > > PublicationAddTables->publication_add_relation, and second time via > > CacheInvalidateRelcacheAll. Can we avoid that by adding a parameter to > > PublicationAddTables? > > Fixed this > > > 2. > > - root_relids =3D GetPublicationRelations(pubform->oid, > > - PUBLICATION_PART_ROOT); > > + root_relids =3D GetIncludedRelationsByPub(pubform->oid, > > + PUBLICATION_PART_ROOT); > > > > To follow the previous function naming pattern, can we rename > > GetIncludedRelationsByPub to GetIncludedPublicationRelations? If we > > agree to this then rename the excluded version of the function as > > well. > > Modified > > > 3. > > +/* > > + * Return the list of relation Oids for a publication. > > + * > > + * For a FOR TABLE publication, this returns the list of relations exp= licitly > > + * included in the publication. > > + * > > + * Publications declared with FOR ALL TABLES/SEQUENCES should use > > + * GetAllPublicationRelations() to obtain the complete set of tables/s= equences > > + * covered by the publication. > > + */ > > +List * > > +GetIncludedRelationsByPub(Oid pubid, PublicationPartOpt pub_partopt) > > > > This is equivalent to the existing function GetPublicationRelations() > > which has more precise comments atop. We can use the same comments > > unless there is any functionality difference. > > Updated it > > > 4. > > --- a/src/backend/catalog/pg_publication.c > > +++ b/src/backend/catalog/pg_publication.c > > @@ -29,6 +29,7 @@ > > #include "catalog/pg_publication.h" > > #include "catalog/pg_publication_namespace.h" > > #include "catalog/pg_publication_rel.h" > > +#include "catalog/pg_subscription.h" > > > > It appears odd to include pg_subscription.h in the publication code. > > Is there a reason for the same? If not then avoid it. > > This was required because we now started using GetPublicationsStr. I > have moved GetPublicationsStr to logical.c from pg_subscription which > is common to both pub and sub. > > > Apart from above, a few cosmetic changes are attached. > > Merged them. > > The attached v47 version patch has the changes for the same. > SIGABRT with normal tables: -------------------------------------- ashutosh@test=3D# select pg_get_publication_effective_tables('t1'::regclass, '{all_pub}'::text[]); server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. Since the function is user-facing, I think we should have test coverage for= it. -- With Regards, Ashutosh Sharma.