Hi, On 6/11/24 10:39, Amit Kapila wrote: > On Mon, Jun 10, 2024 at 7:24 PM vignesh C <vignes...@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
