Re: Streaming replication, and walsender during recovery - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: Streaming replication, and walsender during recovery
Date
Msg-id 4B62930C.40302@enterprisedb.com
Whole thread Raw
In response to Re: Streaming replication, and walsender during recovery  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Streaming replication, and walsender during recovery  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs wrote:
> On Thu, 2010-01-28 at 21:00 +0200, Heikki Linnakangas wrote:
>> I think it is a pretty important safety feature that we keep all the
>> WAL around that's needed to recover the standby. To avoid
>> out-of-disk-space situation, it's probably enough in practice to set
>> checkpoint_timeout small enough in the standby to trigger
>> restartpoints often enough.
> 
> 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.

The other alternative is to refuse to recover if the master can't be
contacted to stream the missing WAL again. Surely that's worse.

Note that we don't have any hard limits on WAL disk usage in general.
For example, if archiving stops working for some reason, you'll
accumulate WAL in the master until it runs out of disk space.

> Reducing
> checkpoint_timeout is the opposite of what you would want to do for
> performance.

Well, make sure you have enough disk space for a higher setting then. It
doesn't seem that hard.

--  Heikki Linnakangas EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Greg Smith
Date:
Subject: Re: WARNING: pgstat wait timeout
Next
From: Simon Riggs
Date:
Subject: Re: Hot Standby: Relation-specific deferred conflict resolution