On Thu, May 23, 2024 at 2:37 AM shveta malik <shveta.ma...@gmail.com> wrote: > c) update_deleted: The row with the same value as that incoming > update's key does not exist. The row is already deleted. This conflict > type is generated only if the deleted row is still detectable i.e., it > is not removed by VACUUM yet. If the row is removed by VACUUM already, > it cannot detect this conflict. It will detect it as update_missing > and will follow the default or configured resolver of update_missing > itself.
I think this design is categorically unacceptable. It amounts to designing a feature that works except when it doesn't. I'm not exactly sure how the proposal should be changed to avoid depending on the timing of VACUUM, but I think it's absolutely not OK to depend on the timing of VACUUm -- or, really, this is going to depend on the timing of HOT-pruning, which will often happen almost instantly. -- Robert Haas EDB: http://www.enterprisedb.com
