RE: Conflict detection for update_deleted in logical replication
От | Zhijie Hou (Fujitsu) |
---|---|
Тема | RE: Conflict detection for update_deleted in logical replication |
Дата | |
Msg-id | TY4PR01MB16907AB0A2ED6F9E5A9D6891B9438A@TY4PR01MB16907.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Conflict detection for update_deleted in logical replication (shveta malik <shveta.malik@gmail.com>) |
Список | pgsql-hackers |
On Tuesday, August 26, 2025 6:45 PM shveta malik <shveta.malik@gmail.com> wrote: > > Please find some more comments: Thanks for the comments! > > > 3) > CREATE SUBSCRIPTION sub CONNECTION '...' PUBLICATION pub WITH > (connect = false, retain_dead_tuples = true, max_conflict_retention_duration > = 5000); > WARNING: deleted rows to detect conflicts would not be removed until the > subscription is enabled > HINT: Consider setting retain_dead_tuples to false. > WARNING: subscription was created, but is not connected > HINT: To initiate replication, you must manually create the replication slot, > enable the subscription, and refresh the subscription. > CREATE SUBSCRIPTION > > With connect=false, we get above messages. Reverse order of WARNINGs will > make more sense as 'not connected' WARNING and HINT clarifies a few things > including that the sub is disabled and needs to be enabled. > Can we attempt doing it provided it does not over-complicate code? I agree it makes sense for reversing the messages. But since this behavior isn't caused by the remaining patches, we can consider it a separate improvement after the main patch is pushed. All other comments look good to me, so addressed in the latest patches. Here is V66 patch set which includes the following changes: [0001] * Enhanced documentation according to Dilip's comments [1]. * Simplified logic by directly using the leader's oldest_nonremovable_xid to locate deleted tuples, according to Amit's comments [2]. * Merged Amit's diff [2]. * Integrated the new NOTICE into the existing CheckSubDeadTupleRetention function according to Amit's feedback [3]. * Some other adjustments according to feedback from [2] [3]. [0002] * Refactored code according to Shveta's comments [4]. * Removed an unnecessary variable according to Shveta's suggestions [5]. * Some other adjustments according to feedback from [4][5][6]. [1] https://www.postgresql.org/message-id/CAFiTN-v2-Jv3UFYQ48pbX%2Bjb%2BMXWoxrfsRXQ_J1s1xqPq8P_zg%40mail.gmail.com [2] https://www.postgresql.org/message-id/CAA4eK1%2BHcrkKfXAwEsXK0waDK8VSx1qjBVj95SmZKPM0vMF%3DQg%40mail.gmail.com [3] https://www.postgresql.org/message-id/CAA4eK1JhYwJhU4vYPGeh8Y46S%2BFS5ciATw5beJKPrkF5ZAu2AQ%40mail.gmail.com [4] https://www.postgresql.org/message-id/CAJpy0uCrHtwN3wgnC26G8M4jQfaMJG3EUU3OY%2BzpwQPeifjmTg%40mail.gmail.com [5] https://www.postgresql.org/message-id/CAJpy0uDpX6jQWC3-cyA38ANT0L_L_qQeWPy2cATzSpLNDha1%3DA%40mail.gmail.com [6] https://www.postgresql.org/message-id/CAJpy0uBQ_v0D3ceuZfJrx%3DzH6-59ORLqj%2BaqZJ7AQnw3vRRcSA%40mail.gmail.com Best Regards, Hou zj
Вложения
В списке pgsql-hackers по дате отправления: