On Thu, May 15, 2025 at 6:02 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Fri, Apr 25, 2025 at 4:06 PM shveta malik <shveta.ma...@gmail.com> wrote: > > > > > > > > Here is V30 patch set includes the following changes: > > > > > > > Thank You for the patch, please find few concerns: > > > > 1) > > By looking at code of ApplyLauncherMain(), it appears that we stopped > > advancing shared-slot's xmin if any of the subscriptions with > > retain_conflict_info is disabled. If a subscription is not being used > > and is disabled forever (or for quite long), that means xmin will > > never be advanced and we will keep accumulating dead-rows even if > > other subscribers with retain_conflict_info are actively setting their > > oldest_xmin. This could be problematic. Here too, there should be some > > way to set stop-conflict-rettention for such a subscription like we do > > for 'subscriber not able to catch-up case'. > > But I understand it can be complex to implement as we do not know for > > how long a subscription is disabled. If we do not find a simpler way > > to implement it, then at least we can document such cases and the > > risks associated with disabled subscription which has > > 'retain_conflict_info' enabled. Thoughts? > > > > Yeah, I agree that this is the case to be worried about but OTOH, in > such cases, even the corresponding logical_slot on the primary won't > be advanced and lead to bloat on the primary as well. So, we can > probably give WARNING when user tries to disable a subscription or > create a disabled subscription with retention flag true. We may need > to write a LOG or raise a WARNING when while exiting apply worker > disables the subscription due disable_on_error option. In addition to > that, we can even document this case. Will that address your concern? >
Yes, it should solve the purpose. Thanks. thanks Shveta
