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>
To: "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>
Cc: 'Bharath Rupireddy' <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [bug fix] ALTER TABLE SET LOGGED/UNLOGGED on a partitioned table does nothing silently
Date: 2020-12-09 12:52:17
Message-ID: 20201209125217.GA32273@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2020-12-09 12:52:32 Re: Refactor MD5 implementations and switch to EVP for OpenSSL
Previous Message Pavel Stehule 2020-12-09 12:34:26 Re: On login trigger: take three