Re: Backward movement of confirmed_flush resulting in data duplication.
Dilip Kumar <dilipbalaut@gmail.com>
From: Dilip Kumar <dilipbalaut@gmail.com>
To: shveta malik <shveta.malik@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Amit Kapila <amit.kapila16@gmail.com>,
"Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, Nisha Moond <nisha.moond412@gmail.com>
Date: 2025-05-13T10:52:39Z
Lists: pgsql-hackers
On Tue, May 13, 2025 at 3:48 PM shveta malik <shveta.malik@gmail.com> wrote: > > Hi All, > > It is a spin-off thread from earlier discussions at [1] and [2]. > > While analyzing the slot-sync BF failure as stated in [1], it was > observed that there are chances that confirmed_flush_lsn may move > backward depending on the feedback messages received from the > downstream system. It was suspected that the backward movement of > confirmed_flush_lsn may result in data duplication issues. Earlier we > were able to successfully reproduce the issue with two_phase enabled > subscriptions (see[2]). Now on further analysing, it seems possible > that data duplication issues may happen without two-phase as well. Thanks for the detailed explanation. Before we focus on patching the symptoms, I’d like to explore whether the issue can be addressed on the subscriber side. Specifically, have we analyzed if there’s a way to prevent the subscriber from moving the LSN backward in the first place? That might lead to a cleaner and more robust solution overall. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
Commits
-
Don't retreat slot's confirmed_flush LSN.
- ad5eaf390c58 18.0 landed
- 7318f241d29c 17.6 landed
- c0f51fde534d 16.10 landed
- 9d1a62359606 15.14 landed
- e68459489c20 14.19 landed
- e323d9df002d 13.22 landed