On 2015-02-22 21:24:56 -0500, Robert Haas wrote:
> On Sat, Feb 21, 2015 at 11:29 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:
> > I am wondering a bit about interaction with wal_keep_segments.
> > One thing is that wal_keep_segments is still specified in number of segments
> > and not size units, maybe it would be worth to change it also?
> > And the other thing is that, if set, the wal_keep_segments is the real
> > max_wal_size from the user perspective (not from perspective of the
> > algorithm in this patch, but user does not really care about that) which is
> > somewhat weird given the naming.
>
> It seems like wal_keep_segments is more closely related to
> wal_*min*_size. The idea of both settings is that each is a minimum
> amount of WAL we want to keep around for some purpose. But they're
> not quite the same, I guess, because wal_min_size just forces us to
> keep that many files around - they can be overwritten whenever.
> wal_keep_segments is an amount of actual WAL data we want to keep
> around.
>
> Would it make sense to require that wal_keep_segments <= wal_min_size?
I don't think so. Right now checkpoint_segments is a useful tool to
relatively effectively control the amount of WAL that needs to be
replayed in the event of a crash. wal_keep_segments in contrast doesn't
have much to do with the normal working of the system, except that it
delays recycling of WAL segments a bit.
With a condition like above, how would you set up things that you have
50k segments around for replication (say a good days worth), but that
your will never have to replay more than ~800 segments (i.e. something
like checkpoint_segments = 800)?
Am I missing something?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services
