Re: Fix WITHOUT OVERLAPS multirange with location replication

Hi,

On Fri, Oct 16, 2026 at 2:57 PM Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
>
> Thanks for updated patches. The fix looks good to me. A few comments:
>
> 1) v5_PG18-0001: the commit message mentions
> RelationFindDeletedTupleInfoByIndex() and the update_deleted vs
> update_missing case, but it doesn't apply to PG18. Maybe that part
> could be dropped.

Thanks for the comments.

I added a general statement that update_delete changes
only apply to PG19 for now.

>
> A couple of nits, please consider if they make sense:
>
> 2) The updated header comment of RelationFindReplTupleByIndex() reads
> a bit confusing to me, how about something like:
>
> * 'skipduplicates' specifies whether the first matching tuple can be used
> * without comparing it against 'searchslot', unless the index scan sets
> * xs_recheck (as with a lossy GiST index for WITHOUT OVERLAPS), in which case
> * only the index key columns are compared, using the index's own equality
> * semantics. If false, all matching tuples are compared against 'searchslot',
> * which must contain a complete row.

Changed as suggested.

>
> 3) 035_conflicts.pl:
> +ok( $node_A->poll_query_until(
> + 'postgres',
> + "SELECT xmin::text = '$pinned_xid' FROM
> pg_replication_slots WHERE slot_name 'pg_conflict_detection'"
> + ),
>
> Should we use "xmin::text::bigint = $pinned_xid" here, to match the
> other slot xmin checks in the same file?

I changed to xmin = $pinned_xid as equality does not need type
conversion.

Please see the updated patch set.

Best Regards,
Zhijie Hou