Re: Fix WITHOUT OVERLAPS multirange with location replication

From: Amit Kapila <amit(dot)kapila16(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 05:14:36
Message-ID: CAA4eK1JsKoZfdjFBC=tgX-YyyxaFKGjfzbXXCKqr1N7BXvFmTw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 9, 2026 at 4:55 PM Paul A Jungwirth
<pj(at)illuminatedcomputing(dot)com> wrote:
>
> On Fri, Oct 9, 2026, Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> wrote:
> >
>
> > 1) The change to RelationFindDeletedTupleInfoByIndex() doesn't seem to
> > be covered by a test. Maybe we could add a case to 035_conflicts.pl?
>
> This was tricky, but I figured out a way to do it. My test adds a row
> on the publisher before creating the subscription, then uses
> copy_data=false. Then I add & delete a "decoy" row with a different
> multirange but the same lossy bounding range. When the publisher
> updates the first row, it gets update_deleted before the fix and
> update_missing after.
>

I think this test is timing dependent because if Delete happens before
Update, the conflict slot could be updated and the row could be
removed. If it is too tricky/tough to write this test, we can even
skip it.

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-10-11 05:51:09 Re: Fix WITHOUT OVERLAPS multirange with location replication
Previous Message Peter Geoghegan 2026-10-11 04:41:36 Buffer pin leak in hash index bucket splits