On Mon, Nov 11, 2019 at 7:53 AM Michael Paquier <mich...@paquier.xyz> wrote: > > On Sun, Nov 10, 2019 at 10:43:33AM +0530, Amit Kapila wrote: > > On Sun, Nov 10, 2019 at 5:51 AM Jeff Janes <jeff.ja...@gmail.com> wrote: > >> in src/backend/replication/walsender.c, there is the section > >> quoted below. It looks like nothing interesting happens between > >> the GetFlushRecPtr just before the loop starts, and the one inside > >> the loop the first time through the loop. If we want to avoid > >> doing CHECK_FOR_INTERRUPTS(); etc. needlessly, then we should > >> check the result of GetFlushRecPtr and return early if it is > >> sufficiently advanced--before entering the loop. If we don't > >> care, then what is the point of updating it twice with no > >> meaningful action >in between? We could just get rid of the > >> section just before the loop starts. > > > > +1. I also think we should do one of the two things suggested by you. > > I would prefer earlier as it can save us some processing in some cases > > when the WAL is flushed in the meantime by WALWriter. > > So your suggestion would be to call GetFlushRecPtr() before the first > check on RecentFlushPtr and before entering the loop? >
No. What I meant was to keep the current code as-is and have an additional check on RecentFlushPtr before entering the loop. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
