Re: [bug fix] ALTER TABLE SET LOGGED/UNLOGGED on a partitioned table does nothing silently

On 1/27/21 1:00 AM, Kyotaro Horiguchi wrote:
> At Wed, 27 Jan 2021 05:30:29 +0000, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> wrote in
>> From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
>>> "CREATE TABLE" is not "CREATE LOGGED TABLE". We can assume that as
>>> "CREATE <default logged-ness> TABLE", where the default logged-ness
>>> varies according to context. Or it might have been so since the beginning.
>>> Currently we don't have the syntax "CREATE LOGGED TABLE", but we can add
>>> that syntax.
>>
>> Yes, I thought of that possibility after a while too. But I felt a bit(?) hesitant to do it considering back-patching. Also, the idea requires ALTER TABLE ATTACH PARTITION will have to modify the logged-ness property of the target partition and its subpartitions with that of the parent partitioned table. However, your idea is one candidate worth pursuing, including whether or not to back-patch what.
>
> I think this and all possible similar changes won't be back-patched at
> all. It is a desaster for any establish version to change this kind
> of behavior.
>>
>>> We pursue relasing all fixes at once but we might release all fixes other than
>>> some items that cannot be fixed for some technical reasons at the time, like
>>> REPLICA IDENITTY.
>>>
>>> I'm not sure how long we will wait for the time of release, though.
>>
>> Anyway, we have to define the ideal behavior for each ALTER action based on some comprehensible principle. Yeah... this may become a long, tiring journey. (I anticipate some difficulty and compromise in reaching agreement, as was seen in the past discussion for the fix for ALTER TABLE REPLICA IDENTITY. Scary)
>
> It seems to me that we have agreed that the ideal behavior for ALTER
> TABLE on a parent to propagate to descendants. An observed objection
> is that behavior is dangerous for operations that requires large
> amount of resources that could lead to failure after elapsing a long
> time. The revealed difficulty of REPLICA IDENTITY is regarded as a
> technical issue that should be overcome.

This thread seems to be stalled. Since it represents a bug fix is there
something we can do in the meantime while a real solution is worked out?

Perhaps just inform the user that nothing was done? Or get something
into the documentation?

Regards,
--
-David
david(at)pgmasters(dot)net