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: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "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-07-01 04:09:37
Message-ID: AANLkTik5bnbyX5hb1s5FvFxLEkBPQuGBLpI1bz4wYbvk@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Jul 1, 2010 at 11:39 AM, Bruce Momjian <bruce(at)momjian(dot)us> 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 has been
> > replayed and <varname>checkpoint_timeout</> seconds have passed since last
> > restartpoint. In standby mode, a restartpoint is also triggered if
> > <varname>checkoint_segments</> log segments have been replayed since last
> > restartpoint and at least one checkpoint record has been replayed since.

> >> ... In log shipping case, the checkpoint interval
> >> + ? ?on the standby is normally smaller than that on the master.
> >> + ? </para>
> >
> > What does that mean? Restartpoints can't be performed more frequently than
> > checkpoints in the master because restartpoints can only be performed at
> > checkpoint records.

I adopted these Heikki's sentences.

> >> *** a/doc/src/sgml/wal.sgml
> >> --- b/doc/src/sgml/wal.sgml
> >> ***************
> >> *** 424,429 ****
> >> --- 424,430 ----
> >> ? ?<para>
> >> ? ? There will always be at least one WAL segment file, and will normally
> >> ? ? not be more than (2 + <varname>checkpoint_completion_target</varname>)
> >> * <varname>checkpoint_segments</varname> + 1
> >> + ? ?or <varname>checkpoint_segments</> + <xref
> >> linkend="guc-wal-keep-segments"> + 1
> >> ? ? files. ?Each segment file is normally 16 MB (though this size can be
> >> ? ? altered when building the server). ?You can use this to estimate space
> >> ? ? requirements for <acronym>WAL</acronym>.
> >
> > That's not true, wal_keep_segments is the minimum number of files retained,
> > independently of checkpoint_segments. The corret formula is (2 +
> > checkpoint_completion_target * checkpoint_segments, wal_keep_segments)
>
> You mean that the maximum number of WAL files is: ?
>
>     max {
>       (2 + checkpoint_completion_target) * checkpoint_segments,
>       wal_keep_segments
>     }
>
> Just after a checkpoint removes old WAL files, there might be wal_keep_segments
> WAL files. Additionally, checkpoint_segments WAL files might be generated before
> the subsequent checkpoint removes old WAL files. So I think that the maximum
> number is
>
>     max {
>       (2 + checkpoint_completion_target) * checkpoint_segments,
>       wal_keep_segments + checkpoint_segments
>     }
>
> Am I missing something?

I've left this part as it is. Before committing the patch, we need to check
whether my thought is true.

Regards,

-- 
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

Attachment: trigger_restartpoint_doc_v2.patch
Description: application/octet-stream (2.5 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Pavel GolubDate: 2010-07-01 05:59:29
Subject: Re: Keepalives win32
Previous:From: Michael GlaesemannDate: 2010-07-01 03:39:42
Subject: Re: Additional startup logging

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