Re: Simplifying replication

On Thu, Oct 21, 2010 at 8:52 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> On Thu, Oct 21, 2010 at 5:46 PM, Josh Berkus <josh(at)agliodbs(dot)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