|From:||Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>|
|Subject:||Checkpointer on hot standby runs without looking checkpoint_segments|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Hello, I will make this patch start again for this CF.
The requirement for this patch is as follows.
- What I want to get is similarity of the behaviors between
master and (hot-)standby concerning checkpoint
progression. Specifically, checkpoints for streaming
replication running at the speed governed with
checkpoint_segments. The work of this patch is avoiding to get
unexpectedly large number of WAL segments stay on standby
side. (Plus, increasing the chance to skip recovery-end
checkpoint by my another patch.)
- This patch shouldn't affect archive recovery (excluding
streaming). Activity of the checkpoints while recoverying from
WAL archive (Precisely, while archive recovery without WAL
receiver launched.) is depressed to checkpoint_timeout level as
- It might be better if the accelaration can be inhibited. But
this patch does not have the feature. Is it needed?
After the consideration of the past discussion and the another
patch I'm going to put on the table, outline of this patch
becomes as follows.
- Check if it is under streaming replication by new function
WalRcvStarted() which tells whether wal receiver has been
launched so far.
- The implement of WalRcvStarted() is changed from previous
one. Now the state is turned on in WalReceiverMain, at the
point where the state of walRcvState becomes
WALRCV_RUNNING. The behavior of previous implement reading
WalRcvInProgress() was useless for my another patch.
- Determine whether to delay checkpoint by GetLogReplayRecPtr()
instead of GetInsertRecPtr() when WalRcvStarted() says true.
NTT Open Source Software Center
== My e-mail address has been changed since Apr. 1, 2012.
|Next Message||Kyotaro HORIGUCHI||2012-06-08 08:22:01||Skip checkpoint on promoting from streaming replication|
|Previous Message||Andres Freund||2012-06-08 08:11:51||Re: New Postgres committer: Kevin Grittner|