Don't retreat slot's confirmed_flush LSN. Prevent moving the confirmed_flush backwards, as this could lead to data duplication issues caused by replicating already replicated changes.
This can happen when a client acknowledges an LSN it doesn't have to do anything for, and thus didn't store persistently. After a restart, the client can send the prior LSN that it stored persistently as an acknowledgement, but we need to ignore such an LSN to avoid retreating confirm_flush LSN. Diagnosed-by: Zhijie Hou <houzj.f...@fujitsu.com> Author: shveta malik <shveta.ma...@gmail.com> Reviewed-by: Amit Kapila <amit.kapil...@gmail.com> Reviewed-by: Dilip Kumar <dilipbal...@gmail.com> Tested-by: Nisha Moond <nisha.moond...@gmail.com> Backpatch-through: 13 Discussion: https://postgr.es/m/CAJpy0uDZ29P=BYB1JDWMCh-6wXaNqMwG1u1mB4=10ly0x7h...@mail.gmail.com Discussion: https://postgr.es/m/os0pr01mb57164ab5716af2e477d53f6f94...@os0pr01mb5716.jpnprd01.prod.outlook.com Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e323d9df002debb103a58ba2479368c46804a9b6 Modified Files -------------- src/backend/replication/logical/logical.c | 23 +++++++++++++++++++++-- 1 file changed, 21 insertions(+), 2 deletions(-)
