On Wed, Dec 23, 2020 at 7:06 PM Jammie <shailesh.jaml...@gmail.com> wrote: > > Thanks Amit for the response. > Two things : > 1) In our observation via PSQL the advance command as well do not move the > restart_lsn immediately. It is similar to our approach that use the > confirmed_flush_lsn via stream > 2) I am ok to understand the point that we are not reading from the stream so > we might be facing the issue. But the question is why we are able to move the > restart_lsn most of the time by updating the confirmed_flush_lsn via pgJDBC. > But only occasionally it lags behind too far behind. >
I am not sure why you are seeing such behavior. Is it possible for you to debug the code? Both confirmed_flush_lsn and restart_lsn are advanced in LogicalConfirmReceivedLocation. You can add elog to print the values to see the progress. Here, the point to note is that even though we update confirmed_flush_lsn every time with the new value but restart_lsn is updated only when candidate_restart_valid has a valid value each time after a call to LogicalConfirmReceivedLocation. We update candidate_restart_valid in LogicalIncreaseRestartDecodingForSlot which is called only during decoding of XLOG_RUNNING_XACTS record. So, it is not clear to me how in your case restart_lsn is getting advanced without decode? I think if you add some elogs in the code to track the values of candidate_restart_valid, confirmed_flush_lsn, and restart_lsn, you might get some clue. -- With Regards, Amit Kapila.
