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. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
