On Sat, Oct 10, 2026 at 9:31 PM kedar anavardekar <[email protected]> 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.
