On Thursday, August 21, 2025 2:01 PM shveta malik <shveta.ma...@gmail.com> wrote: > > On Wed, Aug 20, 2025 at 12:12 PM Zhijie Hou (Fujitsu) > <houzj.f...@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:
Thanks for the comments. > > 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. Fixed in the V64 patches. > 3) > AlterSubscription(): > * retention will be stopped gain soon in such cases, and > > stopped gain --> stopped again Sorry, I missed this typo in V64, I will fix it in the next version. Best Regards, Hou zj
