Re: Proposal: Cascade REPLICA IDENTITY changes to leaf partitions

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Euler Taveira <euler(at)eulerto(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Proposal: Cascade REPLICA IDENTITY changes to leaf partitions
Date: 2025-12-18 05:31:24
Message-ID: 99E57FD0-29B0-4477-99A6-13F8B404B227@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Dec 18, 2025, at 12:21, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
>>
>> 2) Should we simply use the ONLY keyword to determine whether to propagate the
>> replica identity to partitions instead of adding [NOT] INHERIT? For example, if
>> a user specifies ONLY, it changes the identity of the parent table, and any
>> newly created partitions will adopt this new identity. However, the identities
>> of existing partitions remain unchanged.
>
> The current syntax “ALTER TABLE [ONLY] table_name action”, I think here “ONLY” works in terms of inherited tables but partitions. (I surprisedly find the doc doesn’t explain “ONLY” at all.) The current behavior (without my patch) proves my understanding, “ALTER TABLE table_name REPLICA IDENTITY” only updates the parent table itself.
>
> Given that it is not allowed to inherit a table from either a partitioned table (root/parent) or partition (leaf), reusing the “ONLY" at “ALTER TABLE” level won’t generate a conflict. But the problem is, we will have to revisit all ALTER TABLE actions to see if they can propagate to partitions when the target table is a partitioned table. In that case, scope of this patch is extremely extended.
>
> The current approach adding INHERIT to the action “REPLICA IDENTIFY” has no global impacts. If you look at the patch, the syntax this patch uses is:
> ```
> ALTER TABLE ...
> REPLICA IDENTITY { DEFAULT [ INHERIT | NO INHERIT ] |
> USING INDEX index_name |
> FULL [ INHERIT | NO INHERIT ] |
> NOTHING [ INHERIT | NO INHERIT ] }
> ```
> It explicitly avoids the complexity of “USING INDEX”, thus we don’t have to mention any exceptions in docs.
>
> Amit, what do you think?

I read through the doc of “ALTER TABLE” again, and got some findings.

```
name - The name (optionally schema-qualified) of an existing table to alter. If ONLY is specified before the table name, only that table is altered. If ONLY is not specified, the table and all its descendant tables (if any) are altered. Optionally, * can be specified after the table name to explicitly indicate that descendant tables are included.
```

For table name, it says "If ONLY is specified before the table name, only that table is altered. If ONLY is not specified, the table and all its descendant tables (if any) are altered.” Here, I think we can “descendant tables” as both inherited table or partition table, as they are mutually exclusive.

And for “DISABLE/ENABLE [ REPLICA | ALWAYS ] TRIGGER”, the doc says:
```
DISABLE/ENABLE [ REPLICA | ALWAYS ] TRIGGER

When this command is applied to a partitioned table, the states of corresponding clone triggers in the partitions are updated too, unless ONLY is specified.
```

Here, ONLY is used for partition table. From this perspective, “REPLICA IDENTITY” not propagating to children feels like a “bug”.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-12-18 05:40:24 Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)
Previous Message VASUKI M 2025-12-18 05:14:05 Re: Custom oauth validator options