Skip site navigation (1) Skip section navigation (2)

Re: Streaming Replication: Checkpoint_segment and wal_keep_segments on standby

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "Sander, Ingo (NSN - DE/Munich)" <ingo(dot)sander(at)nsn(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Streaming Replication: Checkpoint_segment and wal_keep_segments on standby
Date: 2010-05-28 02:12:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, May 27, 2010 at 11:13 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I guess this happens because the frequency of checkpoint on the standby is
>> too lower than that on the master. In the master, checkpoint occurs for every
>> consumption of three segments because of "checkpoint_segments = 3". On the
>> other hand, in the standby, only checkpoint_timeout has effect, so checkpoint
>> occurs for every 30 minutes because of "checkpoint_timeout = 30min".
>> The walreceiver should signal the bgwriter to start checkpoint if it has
>> received more than checkpoint_segments WAL files, like normal processing?
> Is this also an issue when using log shipping, or just with SR?

When using log shipping, checkpoint_segments always doesn't trigger a
checkpoint. So recovery after the standby crashes might take unexpectedly
long since redo starting point might be old.

But in file-based log shipping, since WAL files don't accumulate in
pg_xlog directory on the standby, even if the frequency of checkpoint
is very low, pg_xlog will not be filled with many WAL files. That
accumulation occurs only when using SR.

If we should avoid low frequency of checkpoint itself rather than
accumulation of WAL files, the bgwriter instead of the walreceiver
should check if we've consumed too much WAL, I think. Thought?


Fujii Masao
NTT Open Source Software Center

In response to


pgsql-hackers by date

Next:From: KaiGai KoheiDate: 2010-05-28 02:30:36
Subject: Re: [RFC] Security label support
Previous:From: David FetterDate: 2010-05-28 02:03:12
Subject: Re: Specification for Trusted PLs?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group