Re: Fix WITHOUT OVERLAPS multirange with location replication

On Fri, Oct 9, 2026, Nisha Moond <nisha(dot)moond412(at)gmail(dot)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(at)illuminatedcomputing(dot)com