From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Simplifying replication |
Date: | 2010-10-22 01:52:40 |
Message-ID: | AANLkTineXrnRAkRV4Cs=rmSo0QkWkFRVYQpj0AWXGn2=@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Oct 21, 2010 at 9:09 PM, Josh Berkus <josh(at)agliodbs(dot)com> 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.
>
> Speaking of which, what's the relationship between checkpoint_segments
> and wal_keep_segments? PG seems perfectly willing to let me set the
> latter higher than the former, and it's not documented.
I think it's pretty well explained in the fine manual.
http://www.postgresql.org/docs/current/static/runtime-config-wal.html#GUC-WAL-KEEP-SEGMENTS
> If checkpoint_segments were a hard limit, then we could let admins set
> wal_keep_segments to -1, knowing that they'd set checkpoint_segments to
> the max space they had available.
This assumes that more checkpoint segments is always better, which
isn't true. I might have 100 GB of disk space free, but not want to
replay WAL for 4 days if I have a crash.
I do think that the current default of checkpoint_segments=3 is
pathologically insane, but that's another can of worms.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2010-10-22 02:03:57 | Re: Simplifying replication |
Previous Message | Bruce Momjian | 2010-10-22 01:29:06 | Re: Floating-point timestamps versus Range Types |