| From: | kedar anavardekar <kedar(dot)anavardekar(at)gmail(dot)com> |
|---|---|
| To: | Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com> |
| Cc: | Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(at)eisentraut(dot)org> |
| Subject: | Re: Fix WITHOUT OVERLAPS multirange with location replication |
| Date: | 2026-10-11 04:31:06 |
| Message-ID: | CAJZSXGrGsLXNk=sDZZEEzQvwg-XfbVX9hxTua9CMOQxXYhwHUg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2026-10-11 04:41:36 | Buffer pin leak in hash index bucket splits |
| Previous Message | shihao zhong | 2026-10-11 02:54:31 | Re: [PG19] Wrong results from NOT NULL-based expression simplification |