Re: Review items for EXCEPT TABLE publication

> On Sep 11, 2026, at 12:03, vignesh C <vignesh21(at)gmail(dot)com> wrote:
>
> On Thu, 10 Sept 2026 at 15:01, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>
>> 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;
>
> @Chao Li What do you think about proceeding this way, to keep the
> behavior simple and consistent with table publications?
> That is, return an ERROR when changing an EXCEPT-listed table to
> UNLOGGED, similar to the behavior for INCLUDED tables, and require the
> user to explicitly remove the table from the EXCEPT list first and
> then change it to UNLOGGED.
>
> Regards,
> Vignesh

I am fine with that.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/