On Wed, Apr 22, 2026 at 3:33 PM Zhijie Hou (Fujitsu) <[email protected]> wrote: > > On Wednesday, April 22, 2026 5:54 PM shveta malik <[email protected]> > wrote: > > On Mon, Apr 20, 2026 at 5:43 PM vignesh C <[email protected]> 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. >
+1. -- With Regards, Amit Kapila.
