On Mon, Aug 4, 2025 at 11:46 AM shveta malik <shveta.malik@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.
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.
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.
Thoughts?
[1] - https://www.postgresql.org/message-id/CAD21AoCbjVTjejQxBkyo9kop2HMw85wSJqpB%3DJapsSE%2BKw_iRg%40mail.gmail.com
[2] - https://www.postgresql.org/docs/devel/sql-createsubscription.html
--
With Regards,
Amit Kapila.
