On Fri, Apr 7, 2023 at 11:06 PM Emre Hasegeli <e...@hasegeli.com> wrote: > > I was reading the logical replication code and found a little > unnecessary work we are doing. > > The confirmed_flushed_lsn cannot reasonably be ahead of the > current_lsn, so there is no point of calling > LogicalConfirmReceivedLocation() every time we update the candidate > xmin or restart_lsn.
In fact, the WAL sender always starts reading WAL from restart_lsn, which in turn is always <= confirmed_flush_lsn. While reading WAL, WAL sender may read XLOG_RUNNING_XACTS WAL record with lsn <= confirmed_flush_lsn. While processing XLOG_RUNNING_XACTS record it may update its restart_lsn and catalog_xmin with current_lsn = lsn fo XLOG_RUNNING_XACTS record. In this situation current_lsn <= confirmed_flush_lsn. Does that make sense? -- Best Wishes, Ashutosh Bapat
