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
