On Fri, Oct 9, 2026, Nisha Moond <nisha.moond412@gmail.com> wrote:
>
> Thanks for the patch. I reviewed v1 and tested it manually. I was able
> to reproduce both the wrong-row update/delete and the update_deleted
> misreport (update_deleted reported instead of update_missing with
> retain_dead_tuples) using a multirange key, and the patch fixes both.
Thanks for the review!
> 1) The change to RelationFindDeletedTupleInfoByIndex() doesn't seem to
> be covered by a test. Maybe we could add a case to 035_conflicts.pl?
This was tricky, but I figured out a way to do it. My test adds a row
on the publisher before creating the subscription, then uses
copy_data=false. Then I add & delete a "decoy" row with a different
multirange but the same lossy bounding range. When the publisher
updates the first row, it gets update_deleted before the fix and
update_missing after.
> 2) The header comment of RelationFindReplTupleByIndex() needs an
> update. It still says:
>
> * 'skipduplicates' specifies whether the first matching tuple can be used
> * without comparing it against 'searchslot'.
> -- This no longer holds when the index scan requires a recheck.
Done.
> 3) The commit message could also mention the update_deleted vs.
> update_missing impact, and that this patch fixes it.
Done.
v2 attached, rebased on current master.
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com
