RE: Conflict detection for update_deleted in logical replication

On Wednesday, January 22, 2025 7:54 PM Zhijie Hou (Fujitsu) <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> On Saturday, January 18, 2025 11:45 AM Zhijie Hou (Fujitsu)
> <houzj(dot)fnst(at)fujitsu(dot)com> wrote:
> > I think invalidating the slot is OK and we could also let the apply
> > worker to automatic recovery as suggested in [1].
> >
> > Here is the V24 patch set. I modified 0004 patch to implement the slot
> > Invalidation part. Since the automatic recovery could be an
> > optimization and the discussion is in progress, I didn't implement that part.
>
> The implementation is in progress and I will include it in next version.
>
> Here is the V25 patch set that includes the following change:
>
> 0001
>
> * Per off-list discussion with Amit, I added few comments to mention the
> reason of skipping advancing xid when table sync is in progress and to mention
> that the advancement will not be delayed if changes are filtered out on
> publisher via row/table filter.
>
> 0004
>
> * Fixed a bug that the launcher would advance the slot.xmin when some apply
> workers have not yet started.
>
> * Fixed a bug that the launcher did not advance the slot.xmin even if one of the
> apply worker has stopped conflict retention due to the lag.
>
> * Add a retain_conflict_info column in the pg_stat_subscription view to
> indicate whether the apply worker is effectively retaining conflict
> information. The value is set to true only if retain_conflict_info is enabled
> for the associated subscription, and the retention duration for conflict
> detection by the apply worker has not exceeded
> max_conflict_retention_duration. Thanks Kuroda-san for contributing codes
> off-list.

Here is V25 patch set which includes the following changes:

0004
* Addressed Nisha's comments[1].
* Fixed a cfbot failure[2] in the doc.

New 0005
* The patch allows the launcher to drop and re-create the invalidated slot, if at
least one apply worker has confirmed that the retention duration is now within
the max_conflict_retention_duration.

[1] https://www.postgresql.org/message-id/CABdArM69ukHVQMmnyKpwbYH8aLhXu-d4fGbSiTkq7BBgRWe0TA%40mail.gmail.com
[2] https://cirrus-ci.com/task/5006366856708096?logs=docs_build#L299

Best Regards,
Hou zj