Re: Fix WITHOUT OVERLAPS multirange with location replication

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Aleksander Alekseev 2026-10-12 14:49:58 Re: serializable anomaly - duplicate primary keys