Re: Conflict detection for update_deleted in logical replication
От | Amit Kapila |
---|---|
Тема | Re: Conflict detection for update_deleted in logical replication |
Дата | |
Msg-id | CAA4eK1Jp7AgMedxRrDdMf5KG1=ZBwov-EHze-fGxZmQ85vx4sA@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Conflict detection for update_deleted in logical replication ("Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>) |
Ответы |
RE: Conflict detection for update_deleted in logical replication
|
Список | pgsql-hackers |
On Tue, Jul 29, 2025 at 10:51 AM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote: > > This is the V54 patch set, with only patch 0001 updated to address the latest > comments. > Few minor comments: 1. /* The row to be updated was deleted by a different origin */ CT_UPDATE_DELETED, /* The row to be updated was modified by a different origin */ CT_UPDATE_ORIGIN_DIFFERS, /* The updated row value violates unique constraint */ CT_UPDATE_EXISTS, /* The row to be updated is missing */ CT_UPDATE_MISSING, Is there a reason to keep CT_UPDATE_DELETED before CT_UPDATE_ORIGIN_DIFFERS? I mean why not keep it just before CT_UPDATE_MISSING on the grounds that they are always handled together? 2. Will it be better to name FindRecentlyDeletedTupleInfoByIndex as RelationFindDeletedTupleInfoByIndex to make it similar to existing function RelationFindReplTupleByIndex? If you agree then make a similar change for FindRecentlyDeletedTupleInfoSeq as well. Apart from above, please find a number of comment edits and other cosmetic changes in the attached. -- With Regards, Amit Kapila.
Вложения
В списке pgsql-hackers по дате отправления: