Re: Proposal: Cascade REPLICA IDENTITY changes to leaf partitions

> On Dec 17, 2025, at 16:48, Zhijie Hou (Fujitsu) <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
> On Wednesday, December 17, 2025 3:56 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>> Thank you both for all your advice. Here comes my first implementation of
>> INHERIT in the attached v2 patch.
>>
>> On Wed, Dec 17, 2025 at 8:11 AM Euler Taveira <mailto:euler(at)eulerto(dot)com> wrote:
>>
>>> I wondering if we use INHERIT as default. The main advantage is usability as
>>> Chao Li already mentioned. Is there any cases that having a different
>>> replica identity from parent/partitioned table makes sense?
>>
>> We can leave this topic open for discussion. In my current implementation, NO
>> INHERIT is still the default. But if we decide to switch the default, I can add
>> a new commit that should include only 1 line code change in gram.y and a tiny
>> doc update.
>>
>> 0001 - when a new partition is created, use the parent's replication identity
>> 0002 - add INHERIT | NO INHERIT
>

Hi Zhijie,

Thanks for your feedback and linked information. I think this patch is avoiding the hard problem of “index” RI.

>
> I think there are several design considerations for this proposal:
>
> 1) Since the index names can vary across different partitions, what should be the
> expected behavior if a new partition cannot identify the same replica identity
> key as the root partitioned table?

Index RI is skipped in this patch. INHERT only works for DEFAULT, FULL and NONE.

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

>
> 3) There have been previous discussions on similar proposals[1][2]. It might be
> beneficial to review those debates to see whether any old issues or arguments
> are pertinent to this proposal.
>
> [1] https://www.postgresql.org/message-id/flat/201902041630.gpadougzab7v%40alvherre.pgsql
> [2] https://www.postgresql.org/message-id/flat/OSBPR01MB2982A2738F16722899A50082FECB0%40OSBPR01MB2982.jpnprd01.prod.outlook.com#2e5388a7cde3c10430f8668a6c381b06
>

I read through the both threads. I think the key difference between the patch and the previous one is that this patch only adds “INHERIT” to DEFAULT/FULL/NONE, which is narrow scoped. Let’s see how the folks who involved in the previous discussion will feedback to this patch.

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