Re: Conflict detection for update_deleted in logical replication

On Wed, Aug 20, 2025 at 12:12 PM Zhijie Hou (Fujitsu)
<houzj(dot)fnst(at)fujitsu(dot)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