On Sat, Jul 17, 2010 at 4:22 AM, Heikki Linnakangas
wrote:
>> The patch adds the document about the relationship between a restartpoint
>> and checkpoint_segments parameter.
>
> Thanks, committed with minor editorialization
Thanks.
> There will always be at least one WAL segment file, and w
On 16/07/10 11:13, Fujii Masao wrote:
On Thu, Jul 1, 2010 at 1:09 PM, Fujii Masao wrote:
Thanks for reminding me. I attached the updated patch.
This patch left uncommitted for half a month. No one is interested in
the patch?
Sorry for the lack of interest ;-)
The patch adds the document a
On Thu, Jul 1, 2010 at 1:09 PM, Fujii Masao wrote:
> Thanks for reminding me. I attached the updated patch.
This patch left uncommitted for half a month. No one is interested in
the patch?
The patch adds the document about the relationship between a restartpoint
and checkpoint_segments parameter
On Thu, Jul 1, 2010 at 11:39 AM, Bruce Momjian wrote:
>
> Did these changes ever get into the docs? I don't think so.
Thanks for reminding me. I attached the updated patch.
> > That last sentence is a bit unclear. How about:
> >
> > A restartpoint is triggered if at least one checkpoint record
Did these changes ever get into the docs? I don't think so.
---
Fujii Masao wrote:
> On Thu, Jun 10, 2010 at 7:19 PM, Heikki Linnakangas
> wrote:
> >> --- 1902,1908
> >> ? ? ? ? ?for standby purposes, and the number o
On Thu, Jun 10, 2010 at 7:19 PM, Heikki Linnakangas
wrote:
>> --- 1902,1908
>> for standby purposes, and the number of old WAL segments
>> available
>> for standbys is determined based only on the location of the
>> previous
>> checkpoint and status of WAL archiving
On 10/06/10 09:14, Fujii Masao wrote:
On Thu, Jun 10, 2010 at 12:09 AM, Heikki Linnakangas
wrote:
BTW, should there be doc changes for this? I didn't find anything explaining
how restartpoints are triggered, we should add a paragraph somewhere.
+1
What about the attached patch?
> (descrip
On Thu, Jun 10, 2010 at 12:09 AM, Heikki Linnakangas
wrote:
> Ok, committed with some cosmetic changes.
Thanks!
> BTW, should there be doc changes for this? I didn't find anything explaining
> how restartpoints are triggered, we should add a paragraph somewhere.
+1
What about the attached patc
On 09/06/10 05:26, Fujii Masao wrote:
On Wed, Jun 2, 2010 at 10:24 PM, Fujii Masao wrote:
On Wed, Jun 2, 2010 at 8:40 PM, Heikki Linnakangas
wrote:
On 02/06/10 06:23, Fujii Masao wrote:
On Mon, May 31, 2010 at 7:17 PM, Fujii Masao
wrote:
4) Change it so that checkpoint_segments takes e
On Wed, Jun 2, 2010 at 10:24 PM, Fujii Masao wrote:
> On Wed, Jun 2, 2010 at 8:40 PM, Heikki Linnakangas
> wrote:
>> On 02/06/10 06:23, Fujii Masao wrote:
>>>
>>> On Mon, May 31, 2010 at 7:17 PM, Fujii Masao
>>> wrote:
4) Change it so that checkpoint_segments takes effect in standby mo
On Wed, Jun 2, 2010 at 8:40 PM, Heikki Linnakangas
wrote:
> On 02/06/10 06:23, Fujii Masao wrote:
>>
>> On Mon, May 31, 2010 at 7:17 PM, Fujii Masao
>> wrote:
>>>
>>> 4) Change it so that checkpoint_segments takes effect in standby mode,
>>> but not during recovery otherwise
>>
>> I revised the p
On 02/06/10 06:23, Fujii Masao wrote:
On Mon, May 31, 2010 at 7:17 PM, Fujii Masao wrote:
4) Change it so that checkpoint_segments takes effect in standby mode,
but not during recovery otherwise
I revised the patch to achieve 4). This will enable checkpoint_segments
to trigger a restartpoint
On Mon, May 31, 2010 at 7:17 PM, Fujii Masao wrote:
> 4) Change it so that checkpoint_segments takes effect in standby mode,
> but not during recovery otherwise
I revised the patch to achieve 4). This will enable checkpoint_segments
to trigger a restartpoint like checkpoint_timeout already does,
On 31/05/10 18:14, Tom Lane wrote:
Heikki Linnakangas writes:
The central question is whether checkpoint_segments should trigger
restartpoints or not. When PITR and restartpoints were introduced, the
answer was "no", on the grounds that when you're doing recovery you're
presumably replaying the
Heikki Linnakangas writes:
> The central question is whether checkpoint_segments should trigger
> restartpoints or not. When PITR and restartpoints were introduced, the
> answer was "no", on the grounds that when you're doing recovery you're
> presumably replaying the logs much faster than they
On Mon, May 31, 2010 at 6:37 PM, Heikki Linnakangas
wrote:
> The central question is whether checkpoint_segments should trigger
> restartpoints or not. When PITR and restartpoints were introduced, the
> answer was "no", on the grounds that when you're doing recovery you're
> presumably replaying t
On 30/05/10 06:04, Fujii Masao wrote:
On Fri, May 28, 2010 at 11:12 AM, Fujii Masao wrote:
On Thu, May 27, 2010 at 11:13 PM, Robert Haas 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 ev
On Fri, May 28, 2010 at 11:12 AM, Fujii Masao wrote:
> On Thu, May 27, 2010 at 11:13 PM, Robert Haas 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 thre
Message-
From: ext Fujii Masao [mailto:masao.fu...@gmail.com]
Sent: Thursday, May 27, 2010 4:10 PM
To: Sander, Ingo (NSN - DE/Munich)
Cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Streaming Replication: Checkpoint_segment and
wal_keep_segments on standby
On Thu, May 27, 2010 at 10:13 PM
On Thu, May 27, 2010 at 11:13 PM, Robert Haas 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
On Thu, May 27, 2010 at 10:09 AM, Fujii Masao wrote:
> On Thu, May 27, 2010 at 10:13 PM, Sander, Ingo (NSN - DE/Munich)
> wrote:
>>
>> With the parameter checkpoint_segment and wal_keep_segments the max. number
>> of wal segments are set. If now the max number is reached,
>>
>> (1) the segments a
On Thu, May 27, 2010 at 10:13 PM, Sander, Ingo (NSN - DE/Munich)
wrote:
>
> With the parameter checkpoint_segment and wal_keep_segments the max. number
> of wal segments are set. If now the max number is reached,
>
> (1) the segments are deleted/recycled
> or (2) if the time set by the checkpoint_
With the parameter checkpoint_segment and wal_keep_segments the max. number of
wal segments are set. If now the max number is reached,
(1) the segments are deleted/recycled
or (2) if the time set by the checkpoint_timeout is over, a checkpoint is set
and if possible a deletion/recycling is don
23 matches
Mail list logo
