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

Hi,

Thanks for working!

> The patch applies cleanly for me, and I re-tested it on the latest
> HEAD (6a93535798aa) as well. Could you please now verify v2 once from
> your side?

My fault: I did not pull ad36e360.

> Thanks for pointing this out. I verified the impact in
> RelationFindDeletedTupleInfoSeq().
>
> After my v1, RelationFindDeletedTupleInfoSeq() is not reachable for a
> table whose only key is a deferrable PK when the publisher uses
> DEFAULT or RI/PK, since such tables are now rejected.
>
> But, it is still reachable when the publisher uses RI-FULL. In this
> case, the sequential scan falls back to the deferrable PK columns,
> which should not be used as replica identity. This can match a dead
> row on the key alone and incorrectly report update_deleted instead of
> update_missing.

Yes, it was my intention.

> Thanks for the patch, I've combined your suggested fix and attched
> updated patch v2.

I checked and no comments for the implementation.
Regarding the back patch, the initial issue (FindReplTupleInLocalRel() can cause
a crash) should be done till PG17, but second one (RelationFindDeletedTupleInfoSeq()
can do a wrong decision) should be done only for PG19/master, right? If so the
patch should be separated. Also, a test can be added in 035_conflicts for the
second issue.

Best regards,
Hayato Kuroda
FUJITSU LIMITED