Re: [bug fix] ALTER TABLE SET LOGGED/UNLOGGED on a partitioned table does nothing silently - Mailing list pgsql-hackers
From | Kyotaro Horiguchi |
---|---|
Subject | Re: [bug fix] ALTER TABLE SET LOGGED/UNLOGGED on a partitioned table does nothing silently |
Date | |
Msg-id | 20210127.150012.1400195796371953406.horikyota.ntt@gmail.com Whole thread Raw |
In response to | RE: [bug fix] ALTER TABLE SET LOGGED/UNLOGGED on a partitioned table does nothing silently ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>) |
Responses |
Re: [bug fix] ALTER TABLE SET LOGGED/UNLOGGED on a partitioned table does nothing silently
(David Steele <david@pgmasters.net>)
|
List | pgsql-hackers |
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. > FWIW, I wonder why Postgres decided to allow different logical structure of tables such as DEFAULT values and constraintsbetween the parent partitioned table and a child partition. That extra flexibility might stand in the way toconsensus. I think it'd be easy to understand that partitions are simply physically independent containers that have identicallogical 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
pgsql-hackers by date: