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 1wFNnS-0052Xc-35 for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Apr 2026 02:58:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wFNnS-00BPpE-0X for pgsql-hackers@arkaria.postgresql.org; Wed, 22 Apr 2026 02:58:38 +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.96) (envelope-from ) id 1wFNnR-00BPp1-2S for pgsql-hackers@lists.postgresql.org; Wed, 22 Apr 2026 02:58:37 +0000 Received: from mail-qk1-x72c.google.com ([2607:f8b0:4864:20::72c]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1wFNnP-00000002BZa-1UmC for pgsql-hackers@lists.postgresql.org; Wed, 22 Apr 2026 02:58:36 +0000 Received: by mail-qk1-x72c.google.com with SMTP id af79cd13be357-8e895b9e7cbso480350985a.1 for ; Tue, 21 Apr 2026 19:58:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1776826715; cv=none; d=google.com; s=arc-20240605; b=DutGBakPJpf/9qMCp9eYR+RscRKRVZYxW/iRgGQJRs3/KJLWqSXBSFNA/KnXsMjuQ6 rPSVwbHOtud5aokVb0b1czp91tLfPI5UX6Vc8ZRZGaWllRzdjS+Od0cgiGsbODVoWjgs Obot4OjGyZC1e5MKdcxRo14Vjj7f0GA60dSHZY7erx/jgLdbox4SZ1XtAp240IjVcHGQ gIJd/cfaZBux3sT9zFF0rnbhc/oEEFNt9nrNNXI5p6yEXQ/yY5uqWztkrXVlgoAgDaz4 NvCLwJKdMmMBHe75iFB8o+IwC+cTZqUCJb5fr4v/WpvYjUaHwOdZn9iwqeu/tuAGTkOR HDNw== 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=QyOX0jsli36MqKLGoqkZlbrKKF8L7/WuwYu+M5/ZxIA=; fh=/f/Jp3Cgr1J3IAWTzlOczVB6pZLfm54NiU9N0oPU8ls=; b=d89CXu0IE0SH/MtGKWC7gtxyLY54XRJOeEwpab38RTOE0Qx4/o/lBfg/CYd1b7B1y2 NfD0QwROTnUBWoM8RIT06F9cm4zN4Xhsvw981wRdtphYIhEjilg6F1kXORQ9ZW7/JI8P 6n8dW3gSypoMUoUfWDBslP7KsCvuurnivgc/M1teOvhPMNxs7dhQGPUTGufoXMDq0jHB s90K4wKOk0OfajjcY6UGTWaDz4z9GPxvXQ3f7QzSocb9IzT068L3TYz6ch7J7Eu5ycOf qDX/shWFrq5/YZW2DchZMb+1ecW17wP943w0GC+VaM/HCg5ZL0GobwWnXLkWvPLW+uEG aryg==; 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=20251104; t=1776826715; x=1777431515; 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=QyOX0jsli36MqKLGoqkZlbrKKF8L7/WuwYu+M5/ZxIA=; b=oVZ5KPvhEeG9hBMtyiyrdX6uyLDc5UNuQ+QxIq9A2WS4SjcWthhMUq45s8PLaRSb8x 3e4MH3A0I9GjANEmr16PjvY+Gxh6SkGW+cI1wHtrP0DyB0uNb+/l+E0Ug9OJ1l/RUQTX b01ylmrxKsrNmeASbj4twsJFiswhVXb6btea7Cdb+jV9JdLlG44aAB+C7YCZF67gVIbg 772bbKwCrpbsacOEdSStJCvNtpJoCwZFzjn6MIMnizUGH6D/UfPVhKSPXV3L/ohjwdc+ DHV7wg36ILdexRiODL1oOHs13IRQ/vFOwMbTsm66jPmjt4MkWtqpuGYioi2g82+YYbXM CGpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776826715; x=1777431515; 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=QyOX0jsli36MqKLGoqkZlbrKKF8L7/WuwYu+M5/ZxIA=; b=bJDBILHn/3frhHr6EQEPVxj6tETZYcChCSGKiAiRFfWkKhDdL0aK56EKViOd7r8dWl ucNI31PcLRegsy9ypnyizEbJLjAyUwMx2W0OkkgBcOr8UtmGLcb70+cZbU0c1ZFBX+fh Jv6knqr55CfGzbFExTsTVlNxg/NgVcd3BKjl+KnzwyizVkmXNS5Vj0fRK2A6/aVbhY6P e1W38O3JOEQgd6ioFaRQ3bD0W/WqcBF6HP6LCEBI9Pjvdz6TP8gftF4pz+Gi972pqNub cZD6yy0nWnWE8bxbQh/xXIPDkaDdHJjpg43W4Q0bEkY5iZR9lnVCPH29i0z4LKAOlaqQ 2BsQ== X-Forwarded-Encrypted: i=1; AFNElJ8C5Uur37IEatBxBYVemTROy1v5gHymP/PvrH0qn1D/2gOj2TAZUGpS28locRII68FMOmMPiqou4Y760LIQ@lists.postgresql.org X-Gm-Message-State: AOJu0YzXTroD2rgu2fv8NCHOoemfhTHvXqAYlWEImYIOCIn4IxHgBb3v itpqJgBUs1NSQDYeF3tsmS2fYte4D0ZmN6I8yvVjJ0vyr2pvFMGAac19RP6X9wrvq5H2izEwJyB KrfpvFEBEh4J+SHo4NXs1wDqSX+xUL6k= X-Gm-Gg: AeBDietWEC2DsuOxz8zaXJNvxELRr0sUodoCaYhlp5rkx5z+yQicK7wVZ3pWjS56eOr CH56zWiKjYhECr2Xc6wUepJQfUMsxog6EDM0Ih3ldBSVrxkgIuyYXhiOFM3cS5nPB7nErdLyfu9 M85ohkzNok95c+8Os6u9qVrfyKChl3SuHu5Itlex5uPkcBIs1x/e9QtpH2xdyE+GuoquP1J8iR7 TdMXnuqA+lZwiSkJ3WIesCMjsrTv9YLxwgdUryCWXoVVm1iaN3F0RIXRSDmaEHMuObLOr7HackJ xEOF8p7KCK0rGiaLfQ== X-Received: by 2002:a05:622a:10e:b0:50b:29a6:8696 with SMTP id d75a77b69052e-50e3681d042mr316065881cf.7.1776826714634; Tue, 21 Apr 2026 19:58:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Peter Smith Date: Wed, 22 Apr 2026 12:58:08 +1000 X-Gm-Features: AQROBzCDOJiJEDZ4U75TE_hCbGu4sEUiA1g_U-Zpwjp9zO9Gz-vkY4gVJTFLCkw Message-ID: Subject: Re: Skipping schema changes in publication To: vignesh C Cc: Amit Kapila , Shlok Kyal , Dilip Kumar , shveta malik , Masahiko Sawada , "Hayato Kuroda (Fujitsu)" , Nisha Moond , Ashutosh Sharma , "David G. Johnston" , "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 On Mon, Apr 20, 2026 at 10:13=E2=80=AFPM vignesh C wr= ote: > > Hi, > > When changing a table to UNLOGGED, tables that appear in publications > via EXCEPT clauses (prexcept =3D true) are currently allowed, but their > entries remain in pg_publication_rel. > > For example: > postgres=3D# create table t1(c1 int); > CREATE TABLE > postgres=3D# create publication pub1 for all tables except (table t1); > CREATE PUBLICATION > postgres=3D# alter table t1 set unlogged; > ALTER TABLE > postgres=3D# \d t1 > Unlogged table "public.t1" > Column | Type | Collation | Nullable | Default > --------+---------+-----------+----------+--------- > c1 | integer | | | > Except publications: > "pub1" > > Since UNLOGGED tables are not supported in publications, this leaves > stale catalog entries. This patch removes such entries from > pg_publication_rel when the table is changed to UNLOGGED, and emits a > NOTICE to inform the user. > > Another option considered was to throw an error when setting such > tables to UNLOGGED. However, allowing the operation was preferred, > since UNLOGGED tables do not generate WAL and are not replicated > anyway, so blocking the operation would be unnecessarily restrictive. > > Attached patch has the changes for the same. > > Thoughts? > Hi Vignesh - A couple of review comments for patch v1-0001. =3D=3D=3D=3D=3D=3D Background: I found when altering a published table from LOGGED to UNLOGGED= ... - If it was published by "FOR ALL TABLES" then it just becomes unpublished *silently*. - Ditto if it was published by "FOR TABLES IN SCHEMA" - It seems you only got an error on ALTER LOGGED->UNLOGGED when the published table was specifically published by "FOR TABLE". =3D=3D=3D=3D=3D=3D src/backend/commands/tablecmds.c 1. + /* Find all publications associated with the relation. */ + pubrellist =3D SearchSysCacheList1(PUBLICATIONRELMAP, + ObjectIdGetDatum(RelationGetRelid(rel))); This comment seems misleading. IIUC, it's only going to find relations specifically mentioned by name in the command. Any relations that are associated with the publication due to "FOR ALL TABLES" or "FOR TABLES IN SCHEMA" are not known. ~~~ 2. + (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), + errmsg("cannot change table \"%s\" to unlogged because it is part of a publication", + RelationGetRelationName(rel)), + errdetail("Unlogged relations cannot be replicated."))) This does not seem like a very good error message in the first place (yes, I know this patch did not change it). e.g. a) It says it is "part of a publication", but it does not tell the user which ones. Maybe list them in the message or provide a HINT to say use \d to show them. b) It mixes terminology, first calling it a 'table', and then calling it a 'relation' ~~~ 3. + ereport(NOTICE, + errmsg("relation \"%s\" removed from publication \"%s\" due to being changed to UNLOGGED", + RelationGetRelationName(rel), pubname)); After some consideration, I think that this really should be an ERROR too, not just a NOTICE. Otherwise, if the user toggled the excluded table from LOGGED->UNLOGGED->LOGGED, then the same table would go from being excluded to being included! The consequences of publishing something that was originally *specifically* excluded by the user might be very bad, so IMO it's better to prevent that from happening -- i.e. sharing the same ERROR code that was there before. =3D=3D=3D=3D=3D=3D Kind Regards, Peter Smith. Fujitsu Australia