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

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.

> FWIW, I wonder why Postgres decided to allow different logical structure of tables such as DEFAULT values and constraints between the parent partitioned table and a child partition. That extra flexibility might stand in the way to consensus. I think it'd be easy to understand that partitions are simply physically independent containers that have identical logical structure.

I understand that -- once upon a time the "traditional" partitioning
was mere a use case of inheritance tables. Parents and children are
basically independent from each other other than inherited attributes.
The nature of table inheritance compel column addition to a parent to
inherit to children, but other changes need not to be propagated. As
time goes by, partition becomes the major use and new features added
at the time are affected by the recognition. After the appearance of
native partitioning, the table inheritance seems to be regarded as a
heritage that we need to maintain.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center