Re: Conflict detection for update_deleted in logical replication
От | shveta malik |
---|---|
Тема | Re: Conflict detection for update_deleted in logical replication |
Дата | |
Msg-id | CAJpy0uCP7x_pdVysYohvrjpk0Vtmk36+XfnC_DOPiegekxfBLA@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 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 for the patches. > The retention status is recorded in the pg_subscription catalog > (subretentionactive) to prevent unnecessary retention initiation upon server > restarts. The apply worker is responsible for updating this flag based on the > retention duration. Meanwhile, the column is set to true when retain_dead_tuples > is enabled or when creating a new subscription with retain_dead_tuples enabled, > and it is set to false when retain_dead_tuples is disabled. > +1 on the idea. Please find few initial testing feedback: 1) When it stops, it does not resume until we restart th server. It keeps on waiting in wait_for_publisher_status and it never receives one. 2) When we do: alter subscription sub1 set (max_conflict_retention_duration=0); It does not resume in this scenario too. should_resume_retention_immediately() does not return true due to wait-status on publisher. 3) AlterSubscription(): * retention will be stopped gain soon in such cases, and stopped gain --> stopped again thanks Shveta
В списке pgsql-hackers по дате отправления: