Coding in WalSndWaitForWal

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Coding in WalSndWaitForWal
Date: 2019-11-10 00:20:38
Message-ID: CAMkU=1wqiAPcJXemN255qEDALbicWHMA2REwsTEacyAiJS+HXg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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. The current coding seems confusing, and increases traffic on
a potentially busy spin lock.

/* Get a more recent flush pointer. */
if (!RecoveryInProgress())
RecentFlushPtr = GetFlushRecPtr();
else
RecentFlushPtr = GetXLogReplayRecPtr(NULL);

for (;;)
{
long sleeptime;

/* Clear any already-pending wakeups */
ResetLatch(MyLatch);

CHECK_FOR_INTERRUPTS();

/* Process any requests or signals received recently */
if (ConfigReloadPending)
{
ConfigReloadPending = false;
ProcessConfigFile(PGC_SIGHUP);
SyncRepInitConfig();
}

/* Check for input from the client */
ProcessRepliesIfAny();

/*
* If we're shutting down, trigger pending WAL to be written out,
* otherwise we'd possibly end up waiting for WAL that never gets
* written, because walwriter has shut down already.
*/
if (got_STOPPING)
XLogBackgroundFlush();

/* Update our idea of the currently flushed position. */
if (!RecoveryInProgress())
RecentFlushPtr = GetFlushRecPtr();
else
RecentFlushPtr = GetXLogReplayRecPtr(NULL);

Cheers,

Jeff

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2019-11-10 03:18:27 Re: CountDBSubscriptions check in dropdb
Previous Message Mark Dilger 2019-11-09 22:32:27 Re: Using multiple extended statistics for estimates