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

At Sat, 26 Dec 2020 01:56:02 +0000, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> wrote in
> From: Michael Paquier <michael(at)paquier(dot)xyz>
> > On Wed, Dec 09, 2020 at 09:52:17AM -0300, Alvaro Herrera wrote:
> > > Well, that definition seems unfriendly to me. I prefer the stance
> > > that if you change the value for the parent, then future partitions
> > > inherit that value.
> >
> > That's indeed more interesting from the user perspective. So +1 from me.
>
> As I mentioned as below, some properties apply to that, and some don't.
>
> --------------------------------------------------
> That would be right when the storage property is an optional
> specification such as fillfactor. For example, when I run ALTER
> TABLE mytable SET (fillfactor = 70) and then CREATE TABLE mytable_p1
> PARTITION OF mytable, I find it nice that the fillfactor os
> mytable_p1 is also 70 (but I won't complain if it isn't, since I can
> run ALTER TABLE SET on the parent table again.)
>
> OTOH, CREATE TABLE and CREATE UNLOGGED TABLE is an explicit request
> to create a logged and unlogged relation respectively. I feel it a
> strange? if CREATE TABLE mytable_p1 PARTITION OF mytable creates an
> unlogged partition.
> --------------------------------------------------

"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.

> Anyway, I think I'll group ALTER TABLE/INDEX altering actions based
> on some common factors and suggest what would be a desirable
> behavior, asking for opinions. I'd like to explore the consensus on
> the basic policy for fixes. Then, I hope we will be able to work on
> fixes for each ALTER action in patches that can be released
> separately. I'd like to regist requiring all fixes to be arranged
> at once, since that may become a high bar for those who volunteer to
> fix some of the actions. (Even a committer Alvaro-san struggled to
> fix one action, ALTER TABLE REPLICA IDENTITY.)

I'd vote +1 to:

ALTER TABLE/INDEX on a parent recurses to all descendants. ALTER
TABLE/INDEX ONLY doesn't, and the change takes effect on future
children.

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.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center