RE: Proposal: Cascade REPLICA IDENTITY changes to leaf partitions
| От | Zhijie Hou (Fujitsu) |
|---|---|
| Тема | RE: Proposal: Cascade REPLICA IDENTITY changes to leaf partitions |
| Дата | |
| Msg-id | TY4PR01MB16907A3EB7F855F95E04A595994ABA@TY4PR01MB16907.jpnprd01.prod.outlook.com обсуждение исходный текст |
| Ответ на | Re: Proposal: Cascade REPLICA IDENTITY changes to leaf partitions (Chao Li <li.evan.chao@gmail.com>) |
| Список | pgsql-hackers |
On Wednesday, December 17, 2025 3:56 PM Chao Li <li.evan.chao@gmail.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@eulerto.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 Thanks for updating the patches. 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? 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. 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 Best Regards, Hou zj
В списке pgsql-hackers по дате отправления: