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 по дате отправления: