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.94.2) (envelope-from ) id 1v2DaC-001RWC-1T for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Sep 2025 18:54:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1v2Da9-005Dl3-Vk for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Sep 2025 18:54:14 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1v2Da9-005Dh8-Hh for pgsql-hackers@lists.postgresql.org; Fri, 26 Sep 2025 18:54:14 +0000 Received: from mail-oo1-xc29.google.com ([2607:f8b0:4864:20::c29]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1v2Da7-0004vU-2W for pgsql-hackers@lists.postgresql.org; Fri, 26 Sep 2025 18:54:13 +0000 Received: by mail-oo1-xc29.google.com with SMTP id 006d021491bc7-641259dff27so153874eaf.1 for ; Fri, 26 Sep 2025 11:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758912850; x=1759517650; darn=lists.postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ioihmJIzjbGwLohwxfHw5Btu0/FfijS51Iyawi1HiKI=; b=gs11cdlM76kuUg2r3/2tObopzRjXM0EbC77VAkdnVXIzjLKqDf8eEcObY4G9JOhLkl e3Mv20qFrU4O/6ixrbtltCeK2tJLHXvzmBOw5W7m9YrZP/yH1gF7A/HaL9zD+tPW3lpx /P82x4741I9q5ipEeOf6/nKfBZSBXvavT6SJv+fgBWX9HVa3vF5dWPBjJ2o+sKEyHXF2 TVP7IF5bfwbZfynphp3QiAQHgFHOnV27SDKFmehIDuD+WqTXj1+pL2vkydO5mOg5tbXk d2o1stPruA/fb48u8z0/GIexsJ6qm+fOydAFagxM5el31lo6D2xRfXEIcG3k6N6Lu2k3 pYDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758912850; x=1759517650; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ioihmJIzjbGwLohwxfHw5Btu0/FfijS51Iyawi1HiKI=; b=ap6JuE52LfQ+0rLzvngz5w+gBg9HEGDqtYJNKLSpLiXWagUojuSgajtieFRAI160XA +YHx4IetU0NsXy2O1/Kzej+s2e2BgIkO8zX4vRdn1TwyoQvyKnEEShmbiVUWLPvlneU8 6zbg0mBu42cIacIQdnXMPX3WHrIsS+epcJg5FC1LVHzMc3A6uAGrazI7+Qwj1FzhhR+B MqsbXe+/QshlhzPmTyTqYwLpSlsM1+FC8Z0O+FuXJ3uWJFxl/u9yFA7XZEC2/y+AudLL opgi61CBF45AElsVs4JbwEtb6luEsoqTJiWQpMZpKJUQ5t4TeyCdK6Wo6FuZPtYDYwog 6mCg== X-Forwarded-Encrypted: i=1; AJvYcCWiq5jI/Lg7csRqUfB8rYds/eiQafPdDUT+3mXUtu2tnn8NG91gfpbNYImaKLSYHpxx5fkcA24q4VXn7/wM@lists.postgresql.org X-Gm-Message-State: AOJu0Yw37XVIinUWHd4Q1lDIkjnhEBYCsW4/B8vtWJcVg8NPjr0O4waI Uux2wUbKQpQvCT9I1jcPN1BxKqjpiU0fEjBzH4pDDFpbKOv43AD/yR0xjjOO+aKbmUSd6UOo/Wc 87aVKnzuzlkCzOD4aM2RXL/2qVYhvK8E= X-Gm-Gg: ASbGncsR0wH0zg6s6COsq8tnjWReNLdtht1U3EVv0AxQY3YoFvZlB47mpOuovdsRbOo RRKqxBOBBiyp8fZT3VijWGWHQixn5deTVzYbPfDWmO51zxsq2EQeps9Obq5wp3F+vYfziHdAcZh 5G79t7c8y7fcwyzjBfbGz493VMVs48MRN65Cas7UtmDz7q/PZznIuEX2qkj7zTZOx8s3S1WdsVO y7Gw60PlQ== X-Google-Smtp-Source: AGHT+IEAIjxkbX0UnU4Tm8xlfksaRs90+z/oPwXRgNDHtmvhK8KrCWJOYJHp+ELd2uMlnBQe/6LAI9jTHGIFjQuYDjY= X-Received: by 2002:a05:6808:bcf:b0:438:36af:9deb with SMTP id 5614622812f47-43f50385f4emr4066205b6e.21.1758912850597; Fri, 26 Sep 2025 11:54:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shlok Kyal Date: Sat, 27 Sep 2025 00:23:58 +0530 X-Gm-Features: AS18NWANQI_XIdaUq1gByqLjJK3LLIx2cywdSDSOIOUQbaMqVPP1vZYBzGLZi3I Message-ID: Subject: Re: Skipping schema changes in publication To: vignesh C Cc: Peter Smith , Amit Kapila , "Zhijie Hou (Fujitsu)" , YeXiu <1518981153@qq.com>, Ian Lawrence Barwick , Bharath Rupireddy , PostgreSQL Hackers Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, 25 Sept 2025 at 14:18, vignesh C wrote: > > On Fri, 5 Sept 2025 at 11:57, Shlok Kyal wrote: > > > > On Mon, 25 Aug 2025 at 13:38, Shlok Kyal wrote: > > > > > > On Thu, 21 Aug 2025 at 05:33, Peter Smith wrote: > > > > > > > > Hi Shlok, > > > > > > > > I reviewed your latest v20-0003 patch and have no more comments at > > > > this time; I only found one trivial typo. > > > > > > > > ====== > > > > src/bin/psql/describe.c > > > > > > > > 1. > > > > + /* > > > > + * Footers entries for a publication description or a table > > > > + * description > > > > + */ > > > > > > > > Typo. /Footers entries/Footer entries/ > > > > > > > > > > I have fixed it and attached the updated patches > > > > > The patches were not applying on HEAD and needed a Rebase. Here is the > > rebased patches > > Consider the following scenario: > create table t1(c1 int, c2 int); > create publication pub1 for table t1 except (c1, c2); > > In this case, the publication is created in such a way that no columns > are included, so effectively no data will be replicated to the > subscriber. > However, when attempting an UPDATE, the following error occurs: > postgres=# update t1 set c1 = 2; > ERROR: cannot update table "t1" because it does not have a replica > identity and publishes updates > HINT: To enable updating the table, set REPLICA IDENTITY using ALTER TABLE. > > Is this behavior expected? Hi Vignesh, I think this behaviour is same as other similar cases like: 1. publication on empty table: CREATE TABLE t1(); CREATE PUBLICATION pub1 FOR TABLE t1; postgres=# DELETE FROM t1; ERROR: cannot delete from table "t1" because it does not have a replica identity and publishes deletes HINT: To enable deleting from the table, set REPLICA IDENTITY using ALTER TABLE. 2. All the columns in a table is a generated column: CREATE TABLE t2(a int GENERATED ALWAYS AS (2*2) STORED); CREATE PUBLICATION pub2 FOR TABLE t2 WITH (publish_generated_columns='none'); In this case since "publish_generated_columns=none", should not publish changes for table t2. But we get following: postgres=# DELETE FROM t2; ERROR: cannot delete from table "t2" because it does not have a replica identity and publishes deletes HINT: To enable deleting from the table, set REPLICA IDENTITY using ALTER TABLE. In above cases as well no columns are published but we have the similar error. Given these behaviours in HEAD I think it is okay for EXCEPT column_list to have the similar behaviour when all columns are excluded. Thought? Thanks, Shlok Kyal