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. BTW, I have
noticed that this part of code is same as it was first introduced in
below commit:
commit 5a991ef8692ed0d170b44958a81a6bd70e90585c
Author: Robert Haas <rh...@postgresql.org>
Date: Mon Mar 10 13:50:28 2014 -0400
Allow logical decoding via the walsender interface.
..
..
Andres Freund, with contributions from Álvaro Herrera, and further review by me.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
