On Sun, Nov 10, 2019 at 5:51 AM Jeff Janes <jeff.janes@gmail.com> wrote:
>
> in src/backend/replication/walsender.c, there is the section quoted below. It looks like nothing interesting happens
betweenthe GetFlushRecPtr just before the loop starts, and the one inside the loop the first time through the loop. If
wewant to avoid doing CHECK_FOR_INTERRUPTS(); etc. needlessly, then we should check the result of GetFlushRecPtr and
returnearly if it is sufficiently advanced--before entering the loop. If we don't care, then what is the point of
updatingit 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 <rhaas@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
