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
