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

Re: Streaming replication, and walsender during recovery

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication, and walsender during recovery
Date: 2010-01-29 08:22:56
Message-ID: 1264753376.24669.15265.camel@ebony (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, 2010-01-29 at 09:49 +0200, Heikki Linnakangas wrote:
> 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.

What is the behaviour of the standby if it hits a disk full error while
receiving WAL? Hopefully it stops receiving WAL and then clears enough
disk space to allow it to receive from archive instead? Yet stays up to
allow queries to continue?

-- 
 Simon Riggs           www.2ndQuadrant.com


In response to

pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-01-29 08:31:03
Subject: Re: Hot Standby: Relation-specific deferred conflict resolution
Previous:From: Guillaume SmetDate: 2010-01-29 08:20:19
Subject: Re: Hot Standby: Relation-specific deferred conflict resolution

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