| From: | Zhijie Hou <houzhijie22(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | kedar anavardekar <kedar(dot)anavardekar(at)gmail(dot)com>, Paul A Jungwirth <pj(at)illuminatedcomputing(dot)com>, 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-12 14:50:09 |
| Message-ID: | CAFvd2n-tpUV+=y9hVssopWLJOxfFw00F-y8n1R2UoX0jAvLiMA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Mon, Oct 12, 2026 at 10:29 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Sun, Oct 11, 2026 at 8:58 PM Zhijie Hou <houzhijie22(at)gmail(dot)com> wrote:
> >
> > I think that instead of building a bitmap and passing it to tuples_equal(), we
> > can write a new helper function that directly traverses the index columns in
> > the slot and compares each of them, similar to what identity_key_equal() does
> > in pg_repack. I think that's a more standard approach, because we can use the
> > index's opclass equality function and collation for the comparison rather than
> > reusing the table attributes'. It is also more efficient, since it avoids
> > building a new bitmap and avoids the typecache lookup. It may not show a
> > performance difference, but I feel it's worth doing better in a common code
> > path (update/delete replay) like this one.
>
> About 0001 patch:
> The index is created after the conflict detection
> +# slot's xmin is pinned, so the sequential scan is used; the locally deleted
> +# row 'ABC' must still be reported as update_deleted for the publisher's key
> +# 'abc', exactly as if the index had been used.
>
> It is not clear to me why here the behaviour should be similar to
> index scan? As index is created after the slot is pinned, so isn't it
> okay to behave as there is no index at all? I see the point that for
> live tuples scan we may have used index but for conflicts as the index
> could be created after the tuple we are searching is deleted, we are
> doing sequence scan and comparing just indexed columns and that could
> be seen as inconsistent. As this is sort of a grey area and we are not
> sure whether to change the code or not, I feel we can fix Paul's
> reported issue now as that is a clear bug.
Agreed. We can fix the reported issue for now. I'm attaching a merged patch
that uses the index comparison approach to fix only the reported issue here. I
also improved the test for the update_deleted detection code path to hold
slot.xmin stable, and removed some unnecessary instance creation/deletion to
make it lighter. Please see the updated patch.
Best Regards,
Zhijie Hou
| Attachment | Content-Type | Size |
|---|---|---|
| v4-0001-Fix-wrong-replication-for-multirange-WITHOUT-OVER.patch | application/octet-stream | 13.6 KB |
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Aleksander Alekseev | 2026-10-12 14:49:58 | Re: serializable anomaly - duplicate primary keys |