> 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? Thanks, Kedar
