Use the relation map's index when searching deleted tuples sequentially. When the index cannot be used to find a recently deleted row, RelationFindDeletedTupleInfoSeq() scans the table. It looked up the relation's replica identity or primary key again to determine which columns to compare, which could differ from the index selected when the relation was opened. A concurrent DROP INDEX CONCURRENTLY could remove the replica identity in between, so the search compared the whole row and reported the conflict as update_deleted instead of update_missing.
Use the index recorded in the relation map instead. The relation map already records the replica identity index, or the primary key if there is no replica identity. It also avoids using a deferrable primary key, which cannot serve as a replica identity; using its columns could incorrectly report a deleted row with different values as update_deleted instead of update_missing. Author: Hayato Kuroda <[email protected]> Author: Nisha Moond <[email protected]> Reviewed-by: Vignesh C <[email protected]> Reviewed-by: Zhijie Hou <[email protected]> Reviewed-by: Amit Kapila <[email protected]> Discussion: https://postgr.es/m/CABdArM5ydwdRrpaZyK1q2p3-vY_+pnBtTmkvg_pcM=ghwmh...@mail.gmail.com Discussion: https://postgr.es/m/os7pr01mb1831779ed93f5470ca1d57605f5...@os7pr01mb18317.jpnprd01.prod.outlook.com Backpatch-through: 19 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a72542b7937a846654d9bcb5855bd8c5725a85b5 Modified Files -------------- src/backend/executor/execReplication.c | 49 +++++++++++++++++-------- src/backend/replication/logical/worker.c | 9 +++-- src/include/executor/executor.h | 2 +- src/test/subscription/t/035_conflicts.pl | 63 ++++++++++++++++++++++++++++++++ 4 files changed, 104 insertions(+), 19 deletions(-)
