On Thu, Aug 7, 2025 at 6:05 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Mon, Aug 4, 2025 at 3:11 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Mon, Aug 4, 2025 at 11:46 AM shveta malik <shveta.ma...@gmail.com> wrote: > > > > > > 7) > > > Shall we rename 'max_conflict_retention_duration' to > > > 'max_conflict_info_retention_duration' as the latter one is more > > > clear? > > > > > > > Before bikeshedding on the name of this option, I would like us to > > once again consider whether we should provide this option at > > subscription-level or GUC? > > > > The rationale behind considering it as a subscription option is that > > the different subscriptions may have different requirements for dead > > tuple retention which means that for some particular subscription, the > > workload may not be always high which means that even if temporarily > > the lag_duration (of apply) has exceeded the new option's value, it > > should become okay. So, in such a case users may not want to configure > > max_conflict_retention_duration for a subscription which would > > otherwise lead to stop detection of update_deleted conflict for that > > subscription. > > Yes valid point, and it's also possible that for some subscription > user is okay to not retain dead tuple if it crosses certain duration > OTOH for some subscription it is too critical to retain dead tuple > even if user has to take some performance hit, so might want to have > higher threshold for those slots. > > > The other point is that it is only related to the retain_dead_tuples > > option of the subscription, so providing this new option at the same > > level would appear consistent. > > Yes that's a valid argument, because if the user is setting retain > dead tuples for subscription then only they need to consider setting > duration. > > > I remember that previously Sawada-San has advocated it to provide as > > GUC but I think the recent tests suggest that users should define > > pub-sub topology carefuly to enable retain_dead_tuples option as even > > mentioned in docs[2], so, it is worth considering to provide it at > > subscription-level. > > IMHO, it should be fine to provide the subscription option first and > if we see complaints about inconvenience we may consider GUC as well > in the future.
+1 thanks Shveta
