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 1vR1BN-004MeI-2Q for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Dec 2025 04:43:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vR1BM-000T8O-0q for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Dec 2025 04:43:08 +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 1vR1BL-000T8G-30 for pgsql-hackers@lists.postgresql.org; Thu, 04 Dec 2025 04:43:08 +0000 Received: from mail-pl1-x633.google.com ([2607:f8b0:4864:20::633]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vR1AH-0032My-2H for pgsql-hackers@lists.postgresql.org; Thu, 04 Dec 2025 04:42:03 +0000 Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-2955623e6faso6632165ad.1 for ; Wed, 03 Dec 2025 20:42:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764823318; x=1765428118; 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=fSO1HeU1tZDlOWV3eN5whwQogM0BbjT6I6bHDxpmUf4=; b=Bb04/u06vNLI4jjbcRA6Df2Y27CSCU5Z/XcsiAAlHrvETcbhXzenWg+VXdbh6Nrzr5 NSUYQIvv0IBscQEK4Bp4tYmvKuH4hqicaPHKsusADdXyrGBhNx0XJrBtu0XhjaKVv9H8 VCBiA/OOtdxA1C03j2MD62VEhfx4tet8MXfHk0cb4arFtkCNLxpEW0W2FnYLH5+FMc8x +72lFquHvRBgHAm4L22RjZ50EE8pXZ73YbjQllBNcar83OK9meOXhwLtcCXC9mfLlrEY oaq+mRknwvlURqz0NYMJlJfn+5wNdJzgxR4ayg3FGo7M2MKC9heDb/wyaPI4P9SaYDVA FgwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764823318; x=1765428118; 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=fSO1HeU1tZDlOWV3eN5whwQogM0BbjT6I6bHDxpmUf4=; b=VO7duM6UTUqnMhKhtJ6Ie6wUjegxc70Vjed8GYslwJcbn57yrpqiv8Gb46QmN/Vlia Tx7DloqPChzdHa09l+7iuEGaFmpSAdtVmxY8wOY45sjnUgZmKAYsXdPIXSAjA9q95QG7 f0Sv620MJxglMW+JhL4rqQRS+JX5rZFWaytvTNKQoy3qoJYZRMjdjVdPKYpt2IYMX/j+ sybjTDAXkrjCakHk7i2HGzFkjn1a33TSSxJol52TbmWbsNXU6napCHYYe4DBLmsQBwZO eeLPhe0nvSlwhZj072fqTuQfFRnRQPO6ZxdQs39BrqVVXaaeyIf0uqpIaog5r9m1APdj OTMg== X-Forwarded-Encrypted: i=1; AJvYcCV3zNwRQoJy/PqsZX0DBbYgIZW3Jj6Cczpbfp7P7RQWImYss0LFV1SjYbspy0rxarZhfskOI7+HAN9egFv1@lists.postgresql.org X-Gm-Message-State: AOJu0YxZOsW3CiVxygXRDWo6g1nEuRb8Cv4OGAzuqiq5W7zFND1iMuYN eWwvVO/7oF+bTBnFlao3IQv9EwkIGjNu0mZADUcQAHg7hKarkjSf5L2TpS3Bw0Lxb1j+bhilwgw msmPHZmykKCVDmkQwJCFZY2LrxlcliZ4= X-Gm-Gg: ASbGncvbB5BzGl/bEEmK4MJ3EwFpFPzvA+5k0oP01DIwlvOx8JFpe+djce0uj7J/8as RsYF9blLP0K5PEtV5/AbO1s12vXtbphJM6PZcKTw3zs2ztFInUivpNuN0uC4n8Cw9oTu2IY7b4S ZvEZp2gJFb6X9hzaq2M29FCXgsigWKWsm/aLPL3IDOhc5i+lHMEBAaIl4wTMQJBi/lV/3+BwXW/ KJDJwsKG8BYh937JJwhLwWZE7J3jX0awcXidLRvfGLzRO3+CvsqGt9043QZM3Irj0w7nU8jHVh9 RvkwY/BfmVkcM3mtTn+q75MM48HL5bIDzQxAQ4PAPFAwWN/tXQh7 X-Google-Smtp-Source: AGHT+IH8JEAdgeEsNNu+QvELzwRusj0HtR7+SVohu+2WK9IKd7jCCAFItHtyis2MBM+yXJNasj4iyjaRISvYlCQhG3k= X-Received: by 2002:a17:903:2cb:b0:298:1013:9d11 with SMTP id d9443c01a7336-29da1ea982bmr15840355ad.43.1764823318368; Wed, 03 Dec 2025 20:41:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: shveta malik Date: Thu, 4 Dec 2025 10:11:44 +0530 X-Gm-Features: AWmQ_bnBR-_Ky8K6h1GoFmcez2FBZlKaNSZkCS9__a_Y8gHgqXC9O8P3917tzd8 Message-ID: Subject: Re: Skipping schema changes in publication To: Shlok Kyal Cc: Peter Smith , vignesh C , Amit Kapila , "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 Wed, Dec 3, 2025 at 8:56=E2=80=AFAM shveta malik wrote: > > On Wed, Nov 19, 2025 at 3:34=E2=80=AFPM Shlok Kyal wrote: > > > > > > I have also addressed the comments in [1], [2]. > > > > [1]: https://www.postgresql.org/message-id/CAHut%2BPtRzCD4-0894cutkU_h8= cPNtosN0_oSHn2iAKEfg2ENOQ%40mail.gmail.com > > [2]: https://www.postgresql.org/message-id/CAHut+PuHn-hohA4OdEJz+Zfukfr= 41TvMTeTH7NwJ=3Dwg1+94uNA@mail.gmail.com > > > > Thanks for the patch. Please find a few comments on 001: > > 1) > + bool nulls[Natts_pg_publication]; > + bool replaces[Natts_pg_publication]; > + Datum values[Natts_pg_publication]; > > + memset(values, 0, sizeof(values)); > + memset(nulls, false, sizeof(nulls)); > + memset(replaces, false, sizeof(replaces)); > > Can we initialize all 3 like below? Then we do not need memset. > bool nulls[Natts_pg_publication] =3D {0}; > > 2) > AlterPublicationReset(): > Can we reset the columns in same sequence as they are originally > defined (see pg_publication_d.h), it makes it easy to map when > comparing/reviewing that we do not have missed any. > > 3) > +/* default values for flags and publication parameters */ > ... > +#define PUB_DEFAULT_VIA_ROOT false > +#define PUB_DEFAULT_ALL_TABLES false > +#define PUB_DEFAULT_ALL_SEQUENCES false > +#define PUB_DEFAULT_GENCOLS PUBLISH_GENCOLS_NONE > > These too we can rearrange as per order in pg_publication_d.h > > 4) > + COMPLETE_WITH("ADD", "DROP", "OWNER TO", "RENAME TO", "RESET", "SET"); > > Is it supposed to be in alphabetical order? Looking at others, I do > not think so. If not, then I feel 'SET' first followed by 'RESET' > seems a more obvious choice to me. See similar (ENABLE followed by > DISABLE): > COMPLETE_WITH("CONNECTION", "ENABLE", "DISABLE", "OWNER TO", > > 5) > +DROP TABLE pub_sch1.tbl1; > +DROP SCHEMA pub_sch1; > > We can use 'DROP SCHEMA pub_sch1 CASCADE'. Then we need not to worry > about dropping the associated table(s) (even if we create more in > future in this schema). > 6) Just before AlterPublicationReset-->LockSchemaList does SearchSysCacheExists1(), I dropped the schema concurrently, which resulted in below error: postgres=3D# alter publication pub1 reset; ERROR: schema with OID 16393 does not exist I do not think the user should be seeing this error. For CreatePublication and AlterPublicationSchemas, it makes sense to give an error when it calls LockSchemaList as user has given the schema names himself. But here since schemas are internally fetched, I think it will be logical to skip the error if it gets dropped concurrently. Thoughts? If we plan to skip error, we can do so by passing the flag missing_okay=3Dtrue. See RangeVarGetRelid and other such functions using such a flag. thanks Shveta