Re: Review items for EXCEPT TABLE publication

On Thu, Sep 10, 2026 at 1:24 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
> > On Sep 10, 2026, at 13:39, vignesh C <vignesh21(at)gmail(dot)com> 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.