Robert Haas wrote:
> I've realized another problem with this patch. standby_keep_segments
> only controls the number of segments that we keep around for purposes
> of streaming: it doesn't affect archiving at all. And of course, a
> standby server based on archiving is every bit as much of a standby
> server as one that uses streaming replication. So at a minimum, the
> name of this GUC is very confusing.
Hmm, I guess streaming_keep_segments would be more accurate. Somehow
doesn't feel as good otherwise, though. Any other suggestions?
> We should also probably think a
> little bit about why we feel like it's OK to throw away data that is
> needed for SR to work, but we don't feel like we ever want to throw
> away WAL segments that we can't manage to archive.
Failure to archive is considered more serious, because your continuous
archiving backup becomes invalid if we delete a segment before it's
archived. And a streaming standby server can catch up using the archive
if it falls behind too much. Plus the primary doesn't know how many
standby servers there is, so it doesn't know which segments are still
needed for SR.
> In the department of minor nits, I also don't like the fact that the
> GUC is called standby_keep_segments and the variable is called
> StandbySegments. If we really have to capitalize them differently, we
> should at least make it StandbyKeepSegments, but personally I think we
> should use standby_keep_segments in both places so that it doesn't
> take quite so many greps to find all the references.
Well, it's consistent with checkpoint_segments/CheckPointSegments. There
is no consistent style on naming the global variables behind GUCs. If
you feel like changing it though, I won't object.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
