On Thu, Oct 21, 2010 at 8:52 PM, Greg Stark <gsst...@mit.edu> wrote: > On Thu, Oct 21, 2010 at 5:46 PM, Josh Berkus <j...@agliodbs.com> wrote: >> >>> Agreed, but as a reality check: when I proposed that wal_keep_segments >>> = -1 would keep all WAL segments (for use while the file system was >>> being backed up), I was told administrators shoud compute how much free >>> disk space they had. Obviously easy of use is not our #1 priority. >> >> Depends. Running out of disk space isn't exactly user-friendly either. >> And detecting how much free space is available would be a painful bit >> of platform-dependant code ... > > Nor can we assume we're the only thing using disk space. > > However the user-unfriendliness isn't the fact that administrators > need to determine how much disk they're willing to dedicate to > Postgres. The user-unfriendliness is that they then have to specify > this in terms of WAL log files and also have to know that we sometimes > keep more than that and so on. > > We've done a good job in the past of converting GUC variables to > meaningful units for administrators and users but it's an ongoing > effort. If we need a GUC to control the amount of disk space we use it > should be in units of MB/GB/TB. If we need a GUC for controlling how > much WAL history to keep for recovering standbys or replicas then it > should be specified in units of time. > > Units like "number of wal files" or worse in the case of > checkpoint_segments "number of wal files / 2 - 1" or something like > that.... are terrible. They require arcane knowledge for the > administrator to have a clue how to set.
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. -- 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
