On 1/27/21 1:00 AM, Kyotaro Horiguchi wrote:
> At Wed, 27 Jan 2021 05:30:29 +0000, "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com> wrote in
>> From: Kyotaro Horiguchi <horikyota.ntt@gmail.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
targetpartition and its subpartitions with that of the parent partitioned table. However, your idea is one candidate
worthpursuing, 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...
thismay become a long, tiring journey. (I anticipate some difficulty and compromise in reaching agreement, as was seen
inthe 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@pgmasters.net