Horton

Re: Backward movement of confirmed_flush resulting in data duplication.

Alexander Kukushkin <cyberdemn@gmail.com>

View thread View on postgr.es
From: Alexander Kukushkin <cyberdemn@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, shveta malik <shveta.malik@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, Nisha Moond <nisha.moond412@gmail.com>
Date: 2025-05-14T06:42:42Z
Lists: pgsql-hackers 
Hi Dilip,

On Wed, 14 May 2025 at 08:29, Dilip Kumar <dilipbalaut@gmail.com> wrote:

> What I meant wasn’t that the subscriber is moving the confirmed LSN
> backward, nor was I suggesting we fix it by persisting the LSN on the
> subscriber side. My point was: the fact that the subscriber is sending
> an LSN older than one it has already sent, does that indicate a bug on
> the subscriber side?  And if so, should the logic be fixed there?
>

In my experience, client applications do a lot of surprisingly not smart
things.
However, it doesn't mean that the server should be blindly accepting
whatever LSN client sends.
I tend to agree with Amit, we shouldn't allow confirmed_flush_lsn to move
backwards.

-- 
Regards,
--
Alexander Kukushkin

Commits

  1. Don't retreat slot's confirmed_flush LSN.