On Fri, Oct 9, 2026, Nisha Moond <[email protected]> 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 ~{:-)
[email protected]
v2-0001-Fix-wrong-replication-for-multirange-WITHOUT-OVER.patch
Description: Binary data
