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