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

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> 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 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.

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

Yeah, recurse by default sounded nice. But I didn't find a consensus related to "parent's setting should determine the default for future children." Could you point me there?

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

All fixes at one release seems constricting to me... Reading from the following quote in the past discussion, I understood consistency is a must and simultaneous release is an ideal. So, I think we can release individual fixes separately. I don't think it won't worsen the situation for users at least.

"try to make them all work the same, ideally in one release, rather than changing them at different times, back-patching sometimes, and having no consistency in the details.

BTW, do you think you can continue to work on your REPLICA IDENTITY patch soon?

Regards
Takayuki Tsunakawa