On Wed, 22 Apr 2026 at 15:33, Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Wednesday, April 22, 2026 5:54 PM shveta malik <shveta.malik@gmail.com> wrote:
> > On Mon, Apr 20, 2026 at 5:43 PM vignesh C <vignesh21@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > When changing a table to UNLOGGED, tables that appear in publications
> > > via EXCEPT clauses (prexcept = true) are currently allowed, but their
> > > entries remain in pg_publication_rel.
> > >
> > > For example:
> > > postgres=# create table t1(c1 int);
> > > CREATE TABLE
> > > postgres=# create publication pub1 for all tables except (table t1);
> > > CREATE PUBLICATION postgres=# alter table t1 set unlogged; ALTER TABLE
> > > postgres=# \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.
> > >
> >
> > The main concern of removal table form EXCEPT-list is that once the table is
> > changed back to LOGGED, there is no internal way to add it to the EXCEPT list
> > again.
> >
> > OTOH, raising an ERROR does not seem like a good solution either. When a
> > user converts a table to UNLOGGED, they are effectively excluding it from
> > publications. Therefore, throwing an error for the purpose that "table is part
> > of EXCEPT, cannot convert it to UNLOGGED" does not appear appropriate,
> > since both actions ultimately exclude the table from publication. I think we
> > can keep the current behavior unchanged as it causes no harm.
>
> I also personally prefer keeping the current behavior, as there is no harm in
> doing so, and I'm not sure whether reporting one more ERROR would make users
> happy.
Thanks Hou-san, Amit, and Shveta for your inputs. Based on the
feedback, let's keep the current behavior unchanged
Regards,
Vignesh
