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

Re: Simplifying replication

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Simplifying replication
Date: 2010-10-26 21:32:58
Message-ID: (view raw or whole thread)
Lists: pgsql-hackers
On Tue, Oct 26, 2010 at 8:27 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Thu, 2010-10-21 at 20:57 -0400, Robert Haas wrote:
>> Very true.  But the lack of a -1 setting for wal_keep_segments means
>> that if you would like to take a backup without archiving, you must
>> set wal_keep_segments to a value greater than or equal to the rate at
>> which you generate WAL segments multiplied by the time it takes you to
>> run a backup.  If that doesn't qualify as requiring arcane knowledge,
>> I'm mystified as to what ever could.
> People are missing the point here:
> You have to put the WAL files *somewhere* while you do the base backup.
> PostgreSQL can't itself work out where that is, nor can it work out
> ahead of time how big it will need to be, since it is up to you how you
> do your base backup. Setting a parameter to -1 doesn't make the problem
> go away, it just pretends and hopes it doesn't exist, but screws you
> badly if you do hit the wall.

If you set wal_keep_segments=0, archive_mode=on, and
archive_command=<something>, you might run out of disk space.

If you set wal_keep_segments=-1, you might run out of disk space.

Are you any more screwed in the second case than you are in the first
case?  Why?

Robert Haas
The Enterprise PostgreSQL Company

In response to


pgsql-hackers by date

Next:From: Mladen GogalaDate: 2010-10-26 21:54:57
Subject: Re: Postgres insert performance and storage requirement compared to Oracle
Previous:From: Jon NelsonDate: 2010-10-26 21:27:23
Subject: Re: Postgres insert performance and storage requirement compared to Oracle

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