RE: Conflict detection for update_deleted in logical replication
От | Zhijie Hou (Fujitsu) |
---|---|
Тема | RE: Conflict detection for update_deleted in logical replication |
Дата | |
Msg-id | TY4PR01MB1690798295FC14929B238B2DF9432A@TY4PR01MB16907.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Conflict detection for update_deleted in logical replication (Nisha Moond <nisha.moond412@gmail.com>) |
Ответы |
Re: Conflict detection for update_deleted in logical replication
|
Список | pgsql-hackers |
On Thursday, August 21, 2025 3:47 PM Nisha Moond <nisha.moond412@gmail.com> wrote: > > On Wed, Aug 20, 2025 at 12:12 PM Zhijie Hou (Fujitsu) > <houzj.fnst@fujitsu.com> wrote: > > > > I agree. Here is V63 version which implements this approach. > > > > Thank you Hou-san for the patches. Here are couple of comments: > > 1) Once retention is stopped for all subscriptions and conflict_slot.xmin is > reset to NULL, we are no longer retaining dead tuples. In that case, the warning > shown during subscription disable looks misleading. > > For example sub has already stopped the retention and when disabled - > postgres=# alter subscription sub1 disable; > WARNING: deleted rows to detect conflicts would not be removed until the > subscription is enabled > HINT: Consider setting retain_dead_tuples to false. > ALTER SUBSCRIPTION > > I think we should check if retention is active or not here. > > 2) Regarding the logic in the launcher for advancing the slot’s xmin: > Consider a case where two subscriptions exist, and one of them is disabled > after it has already stopped retention. > Example subscriptions in state: > ... > Here, sub2 is disabled, and since subretentionactive = 'f', it is not retaining > dead tuples anymore. But, the current launcher logic still blocks xmin > advancement as one of the subscriptions with retain_dead_tuples is disabled. > I think the launcher should consider the subretentionactive value and the xmin > should be allowed to advance. Thoughts? I agree that retentionactive needs to be checked in the cases mentioned above. Here is the V64 patch set addressing this concern. This version also resolves the bug reported by Shveta[1], where retention could not resume and was stuck waiting for the publisher status. In addition, I also improved the comments related to the new phases and retentionactive flag. [1] https://www.postgresql.org/message-id/CAJpy0uCP7x_pdVysYohvrjpk0Vtmk36%2BXfnC_DOPiegekxfBLA%40mail.gmail.com Best Regards, Hou zj
Вложения
В списке pgsql-hackers по дате отправления: