Re: Coding in WalSndWaitForWal

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Coding in WalSndWaitForWal
Date: 2019-11-10 05:13:33
Message-ID: CAA4eK1+HcdEAnyVFaaXbMYVPzhhj-O6rESnBs_Bss5kSm6W2hg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. 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(at)postgresql(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-11-10 05:42:40 Re: Handy describe_pg_lock function
Previous Message Amit Kapila 2019-11-10 03:18:27 Re: CountDBSubscriptions check in dropdb