| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> | 
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> | 
| Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: Coding in WalSndWaitForWal | 
| Date: | 2019-11-11 03:25:14 | 
| Message-ID: | CAA4eK1J5kS_gYp9Wg-LNWdQ=QJdaFM5-4gh5V=C38K=qZze8bw@mail.gmail.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On Mon, Nov 11, 2019 at 7:53 AM Michael Paquier <michael(at)paquier(dot)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(dot)janes(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2019-11-11 04:13:40 | Re: cost based vacuum (parallel) | 
| Previous Message | Amit Kapila | 2019-11-11 03:16:54 | Re: CountDBSubscriptions check in dropdb |