On Wed, Jan 15, 2025 at 9:38 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Jan 15, 2025 at 5:57 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > > > Probably retaining dead tuples based on the time duration or its age > > might be other solutions, it would increase a risk of not being able > > to detect update_deleted conflict though. I think in any way as long > > as we accumulate dead tulpes to detect update_deleted conflicts, it > > would be a tradeoff between reliably detecting update_deleted > > conflicts and the performance. > > > > Right, and users have an option for it. Say, if they set max_lag as -1 > (or some special value), we won't invalidate the slot, so the > update_delete conflict can be detected with complete reliability. At > this stage, it is okay if this information is LOGGED and displayed via > a system view. We need more thoughts while working on the CONFLICT > RESOLUTION patch such as we may need to additionally display a WARNING > or ERROR if the remote_tuples commit_time is earlier than the last > time slot is invalidated. >
The more reliable way to do something in this regard would be that if there is a valid and active pg_conflict_detection (or whatever we name this slot) then consider the update_missing conflict detected as reliable. Otherwise, the conflict_type will depend on whether the vacuum has removed the dead row. so, the conflict management system or users would easily know when to rely on this update_missing conflict type. -- With Regards, Amit Kapila.
