On Thu, Sep 10, 2026 at 1:24 PM Chao Li <[email protected]> wrote: > > > On Sep 10, 2026, at 13:39, vignesh C <[email protected]> wrote: > > > > Finding #5: SET UNLOGGED on an excluded table produces an unrestorable > > catalog state > > > > For v1-0005, the code change itself looks good to me. > > However, I have some concern about the design. Since a table in the EXCEPT > list is not published anyway, do we really need to reject SET UNLOGGED? Would > it make more sense to remove the table from the EXCEPT list and emit a NOTICE > to inform the user? >
I think removing the publication membership during another DDL will unnecessarily widen the scope of publication memberships. For example, consider, later one does, ALTER TABLE t SET LOGGED emits nothing, and t is now published by p. This is the damaging one and NOTICE in the previous message doesn't prevent it. Either the subscriber lacks t, in which case apply fails and the whole subscription stalls, or it has t, in which case data the user deliberately excluded starts flowing. Both are triggered by a local DDL statement with no indication that replication scope just widened. Also, it would be inconsistent with the INCLUDED case where we are giving ERROR. I feel giving ERROR is the right thing to do here, so that users can explicitly remove it from EXCEPT list and then later if She wants to make table LOGGED again, She can execute following steps: BEGIN; ALTER TABLE t SET LOGGED; ALTER PUBLICATION p SET ALL TABLES EXCEPT (TABLE t, ...); COMMIT; -- With Regards, Amit Kapila.
