Re: Fix apply worker crash when subscriber table has only a deferrable primary key

On Wed, Sep 30, 2026 at 2:47 PM Hayato Kuroda (Fujitsu)
<kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
>
> Hi Amit,
>
> > The caller of RelationFindDeletedTupleInfoSeq() already has
> > information localindexoid/idxisreplident, why can't we use those
> > values instead of computing the same information again? I am afraid
> > that computing such an information again could lead to symptoms what
> > we fixed in the recent commit
> > ad36e3608c8cb6f0848737ec81e548d4d3a0af3c.
>
> Your point meant not to get the info from the relcache because it can be
> invalidated by the concurrent DDLs, right? I think it's possible, but the
> additional computation might be needed since bitmapset for key columns are not
> cached on the relmap now. Attached top-up patch implemented the idea, can you
> see it's same as your expectation?
> Test code just showed my understanding, not intended to be included for now.
>

My understanding is also the same. Thanks for the patch; I’ve verified the fix.

Here is the updated version, merged with v3-0001.

v4-0001: Updated stale comments in RelationFindDeletedTupleInfoSeq(),
corrected the new comments in FindDeletedTupleInLocalRel(), and added
an assertion that the whole row is compared only when the publisher
uses REPLICA IDENTITY FULL.
v4-0002: Moved both tests in 035_conflicts.pl into a separate patch:
the deferrable primary key case and your concurrent DROP INDEX case,
as these are not intended for commit.

Both patches apply cleanly on HEAD and PG19, and I’ve tested them on
both branches.

> > I suggest let's first fix this one and then we can discuss your other patch.
>
> Yeah, it's related with PG19 issue thus it has higher priority.
>

+1

--
Thanks,
Nisha