RE: Conflict detection for update_deleted in logical replication

Поиск
Список
Период
Сортировка
От Zhijie Hou (Fujitsu)
Тема RE: Conflict detection for update_deleted in logical replication
Дата
Msg-id TY4PR01MB169073ACEAB879AD83E84AFBD9407A@TY4PR01MB16907.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: Conflict detection for update_deleted in logical replication  (shveta malik <shveta.malik@gmail.com>)
Ответы RE: Conflict detection for update_deleted in logical replication
Список pgsql-hackers
On Friday, August 29, 2025 6:28 PM shveta malik <shveta.malik@gmail.com>:
> 
> On Fri, Aug 29, 2025 at 11:49 AM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>
> wrote:
> >
> > Here is the new version patch set which also addressed Shveta's
> comments[1].
> >
> 
> Thanks for the patch.
> 
> On 001 alone, I’m observing a behavior where, if sub1 has stopped retention,
> and I then create a new subscription sub2, the worker for
> sub2 fails to start successfully. It repeatedly starts and exits, logging the
> following message:
> 
> LOG:  logical replication worker for subscription "sub2" will restart because
> the option retain_dead_tuples was enabled during startup
> 
> Same things happen when I disable and re-enable 'retain_dead_tuple' of any
> sub once the slot has invalid xmin.

I think this behavior is because slot.xmin is set to an invalid number, and 0001
patch has no slot recovery logic, so even if retentionactive is true, newly
created subscriptions cannot have a valid oldest_nonremovable_xid.

After thinking more, I decided to add slot recovery functionality to 0001 as
well, thus avoiding the need for additional checks here. I also adjusted
the documents accordingly.

Here is the V69 patch set which addressed above comments and the
latest comment from Nisha[1].

[1] https://www.postgresql.org/message-id/CABdArM7GBa8kXCdOQw4U--tKgapj5j0hAVzL%3D%3DB3-fkg8Gzmdg%40mail.gmail.com

Best Regards,
Hou zj

Вложения

В списке pgsql-hackers по дате отправления: