Robert Haas wrote:
> > 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.
LOL. Time machine required (both forward and backward time options).
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +