On Thu, Oct 21, 2010 at 9:09 PM, Josh Berkus <j...@agliodbs.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
