On 2015-02-22 21:24:56 -0500, Robert Haas wrote: > On Sat, Feb 21, 2015 at 11:29 PM, Petr Jelinek <p...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
