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

Re: Streaming replication, and walsender during recovery

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication, and walsender during recovery
Date: 2010-01-29 08:31:08
Message-ID: 3f0b79eb1001290031n1e3a94f5k297142a0b21b844e@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Jan 29, 2010 at 4:13 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> Hmm, I'm sorry but that's bogus. Retaining so much WAL that we are
> strongly in danger of blowing disk space is not what I would call a
> safety feature. Since there is no way to control or restrain the number
> of files for certain, that approach seems fatally flawed. Reducing
> checkpoint_timeout is the opposite of what you would want to do for
> performance.

Why do you worry about that only in the standby? The primary (i.e.,
postgres in the normal mode) has been in the same situation until now.

But usually the cycle of restartpoint is longer than that of
checkpoint. Because restartpoint occurs when the checkpoint record
has been replayed AND checkpoint_timeout has been reached.
So the WAL files might more easily accumulate in the standby.

To improve the situation, I think that we need to use
checkpoint_segment/timeout as a trigger of restartpoint, regardless
of the checkpoint record. Though I'm not sure that is possible and
should be included in v9.0.

Regards,

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

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-01-29 08:41:19
Subject: Re: Streaming replication, and walsender during recovery
Previous:From: Simon RiggsDate: 2010-01-29 08:31:03
Subject: Re: Hot Standby: Relation-specific deferred conflict resolution

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