Horton

RE: Conflict detection for update_deleted in logical replication

Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com>

View thread View on postgr.es
From: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, shveta malik <shveta.malik@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Nisha Moond <nisha.moond412@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, vignesh C <vignesh21@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>
Date: 2025-09-01T11:37:30Z
Lists: pgsql-hackers

Attachments

On Monday, September 1, 2025 12:45 PM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote:
> 
> On Friday, August 29, 2025 6:28 PM shveta malik <shveta.malik@gmail.com>:
> >
> > On Fri, Aug 29, 2025 at 11:49 AM Zhijie Hou (Fujitsu)
> > <houzj.fnst@fujitsu.com>
> > wrote:
> > >
> > > Here is the new version patch set which also addressed Shveta's
> > comments[1].
> > >
> >
> > Thanks for the patch.
> >
> > On 001 alone, I’m observing a behavior where, if sub1 has stopped
> > retention, and I then create a new subscription sub2, the worker for
> > sub2 fails to start successfully. It repeatedly starts and exits,
> > logging the following message:
> >
> > LOG:  logical replication worker for subscription "sub2" will restart
> > because the option retain_dead_tuples was enabled during startup
> >
> > Same things happen when I disable and re-enable 'retain_dead_tuple' of
> > any sub once the slot has invalid xmin.
> 
> I think this behavior is because slot.xmin is set to an invalid number, and 0001
> patch has no slot recovery logic, so even if retentionactive is true, newly created
> subscriptions cannot have a valid oldest_nonremovable_xid.
> 
> After thinking more, I decided to add slot recovery functionality to 0001 as well,
> thus avoiding the need for additional checks here. I also adjusted the
> documents accordingly.
> 
> Here is the V69 patch set which addressed above comments and the latest
> comment from Nisha[1].

I reviewed the patch internally and tweaked a small detail of the apply worker
to reduce the waiting time in the main loop when max_retention_duration is
defined (set wait_time = min(wait_time, max_retention_duration)). Also, I added
a simple test in 035_conflicts.pl of 0001 to verify the new sub option.

Here is V70 patch set.

Best Regards,
Hou zj

Commits

  1. Fix intermittent BF failures in 035_conflicts.

  2. Resume conflict-relevant data retention automatically.

  3. Fix intermittent test failure introduced in 6456c6e2c4.

  4. Fix Coverity issue reported in commit a850be2fe.

  5. Add test to prevent premature removal of conflict-relevant data.

  6. Post-commit review fixes for 228c370868.

  7. Add max_retention_duration option to subscriptions.

  8. Detect and report update_deleted conflicts.

  9. Preserve conflict-relevant data during logical replication.

  10. Integrate FullTransactionIds deeper into two-phase code

  11. Improve checks for GUC recovery_target_timeline

  12. Prevent excessive delays before launching new logrep workers.

  13. Keep WAL segments by slot's last saved restart LSN

  14. Rework some code handling pg_subscription data in psql and pg_dump

  15. Use generateClonedIndexStmt to propagate CREATE INDEX to partitions.