Thread

Re: Conflict detection for update_deleted in logical replication

Nisha Moond <nisha.moond412@gmail.com> — 2025-08-21T07:46:57Z

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:
subname | subenabled | subretaindeadtuples | submaxconflretention |
subretentionactive
---------+------------+---------------------+----------------------+--------------------
sub1    | t          | t                   |                  100 | t
sub2    | f          | t                   |                  100 | f

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?

--
Thanks,
Nisha