Re: Fix WITHOUT OVERLAPS multirange with location replication

On Sat, Oct 10, 2026 at 9:31 PM kedar anavardekar
<kedar(dot)anavardekar(at)gmail(dot)com> wrote:
>
> > v2 attached, rebased on current master.
>
> Hi Paul,
> Thank you for the patches.
> I tested v2-0001 and have two results and one question.
>
> 1. Lossy REPLICA IDENTITY index (034_temporal.pl scenario)
> I used a multirange WITHOUT OVERLAPS identity index with two rows
> whose bounding ranges are the same.
>
> Without the patch, the apply worker reports conflict=update_exists.
> With the patch, it reports conflict=conflict=update_origin_differs.
>
> 2. update_missing vs update_deleted (035_conflicts.pl scenario)
>
> Without the patch, the conflict is reported as update_deleted.
> With the patch, it is reported as update_missing.
> That matches what the test expects. t/034_temporal.pl and
> t/035_conflicts.pl both pass for me.
>
> Question about RelationFindReplTupleByIndex()
> The scan uses the idxoid passed in. The recheck bitmap comes from
> RelationGetIndexAttrBitmap(rel, ...), which describes the relation's
> currently configured identity or PK index. This might not be the index
> that was scanned.
>
> worker.c (around line 3250) mentions that a concurrent index update
> can change the index's validity or identity while the worker still
> holds a cached index OID. If that happens, the bitmap may no longer
> describe the scanned index. The recheck would then compare unrelated
> columns, or all columns if no bitmap is available. The incoming
> old-key tuple doesn't necessarily contain those other values. The real
> candidate could then be rejected, which would give a missing-row
> result or the wrong conflict classification. The same applies to
> RelationFindDeletedTupleInfoByIndex().
>
> I haven't reproduced this concurrency case yet. as much as I have
> tried, ordinary DDL is not triggering it for a GiST WITHOUT OVERLAPS
> index.
>
> Would it make sense to build the recheck bitmap from the scanned
> index's own key columns (idxrel->rd_index->indkey, up to indnkeyatts)?
> That would remove the dependency on the relation's current identity.
> Or do you think the current approach is safe for a reason I'm missing?
>

IIUC, the current approach is safe because concurrent operations won't
change index columns. Having said that, I think your suggested
approach sounds more robust. Additionally, I think we can build the
bitmap inside (if (eq == NULL)) check to avoid building it again and
again for each tuple scan.

--
With Regards,
Amit Kapila.