Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: masao(dot)fujii(at)gmail(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [BUG] Checkpointer on hot standby runs without looking checkpoint_segments
Date: 2012-04-17 03:29:54
Message-ID: 20120417.122954.125898810.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello, thank you for comment.

> > In the backported version to 9.1.3, bgwriter.c is modified
> > instead of checkpointer.c in 9.2. And GetWalRcvWriteRecPtr() is
> > used as the equivalent of GetStandbyFlushRecPtr() in 9.2.
>
> In 9,2, GetXLogReplayRecPtr() should be used instead of
> GetStandbyFlushRecPtr(). A restartpoint is scheduled to finish
> before next restartpoint is triggered. A restartpoint is
> triggered if too much WAL files have been replayed since last
> restartpoint. So a restartpoint should be scheduled according
> to the replay location not the receive location.

I agree with it basically. But I've get confused to look into
GetStandbyFlushRecPtr().

| if (XLByteLT(receivePtr, replayPtr))
| return XLByteLT(replayPtr, restorePtr) ? restorePtr : replayPtr;
| else
| return XLByteLT(receivePtr, restorePtr) ? restorePtr : receivePtr;

This seems imply receivePtr may be behind replayPtr. I don't
understand what condition makes it but anyway the bottom line I
think is that a restartpoint should be based on WALs surely
synced. So I choosed GetStandbyFlushRecPtr() to read the
location.

If receivePtr/restorePtr always precede or are equal to
replayPtr, I prefer GetXLogReplayRecPtr() as you suggest.

(And some comment about the order among these pointers might
should be supplied for the part)

> I think that basically it's better not to change the comments
> (i.e., not to add the line feed) if their contents are the same
> as previous ones, to highlight what you actually changed in the
> patch.

Hmm. It is a priority matter between pointing up in or
compactness of a patch and consistency in outcome of that. I
think the latter takes precedence over the former.

Altough, I could have found a description on better balance. But
more than that, I've found fill-column for this comment be too
short...

> Typo: RedoRecptr should be RedoRecPtr?

I think that's right. I've unconsciously brought that spelling
from the orignal comment.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

== My e-mail address has been changed since Apr. 1, 2012.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Meskes 2012-04-17 03:52:08 Re: ECPG FETCH readahead
Previous Message Alex 2012-04-17 03:26:39 Re: Bug tracker tool we need