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

On Wed, Dec 9, 2020 at 6:22 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> On 2020-Dec-09, tsunakawa(dot)takay(at)fujitsu(dot)com wrote:
>
> > From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> > > But what happens when you create another partition after you change the
> > > "loggedness" of the partitioned table?
> >
> > The new partition will have a property specified when the user creates
> > it. That is, while the storage property of each storage unit
> > (=partition) is basically independent, ALTER TABLE on a partitioned
> > table is a convenient way to set the same property value to all its
> > underlying storage units.
>
> 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.
>
> > I got an impression from the discussion that some form of consensus on
> > the principle was made and you were trying to create a fix for REPLICA
> > IDENTITY. Do you think the principle was unclear and we should state
> > it first (partly to refresh people's memories)?
>
> I think the principle was sound -- namely, that we should make all those
> commands recurse by default, and for cases where it matters, the
> parent's setting should determine the default for future children.
>
> > I'm kind of for it, but I'm hesitant to create the fix for all ALTER
> > actions, because it may take a lot of time and energy as you were
> > afraid. Can we define the principle, and then create individual fixes
> > independently based on that principle?
>
> That seems acceptable to me, as long as we get all changes in the same
> release. What we don't want (according to my reading of that
> discussion) is to change the semantics of a few subcommands in one
> release, and the semantics of a few other subcommands in another
> release.
>

I'm not sure how many more of such commands exist which require changes.

How about doing it this way?

1) Have a separate common thread listing the commands and specifying
clearly the agreed behaviour for such commands.
2) Whenever the separate patches are submitted(hopefully) by the
hackers for such commands, after the review we can make a note of that
patch in the common thread.
3) Once the patches for all the listed commands are
received(hopefully) , then they can be committed together in one
release.

With Regards,
Bharath Rupireddy.
EnterpriseDB: http://www.enterprisedb.com