Re: confirmed flush lsn seems to be move backward in certain error cases

Hi,

On 6/11/24 10:39, Amit Kapila wrote:
> On Mon, Jun 10, 2024 at 7:24 PM vignesh C <vignesh21@gmail.com> wrote:
>>
>> I have re-verified  the issue by running the tests in a loop of 150
>> times and found it to be working fine. Also patch applies neatly,
>> there was no pgindent issue and all the regression/tap tests run were
>> successful.
>>
> 
> Thanks, I have pushed the fix.
> 

Sorry for not responding to this thread earlier (two conferences in two
weeks), but isn't the pushed fix addressing a symptom instead of the
actual root cause?

Why should it be OK for the subscriber to confirm a flush LSN and then
later take that back and report a lower LSN? Seems somewhat against my
understanding of what "flush LSN" means.

The commit message explains this happens when the subscriber does not
need to do anything for - but then why shouldn't it just report the
prior LSN, in such cases?

I haven't looked into the details, but my concern is this removes an
useful assert, protecting us against certain type of bugs. And now we'll
just happily ignore them. Is that a good idea?


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company