On Mon, Jul 30, 2018 at 4:43 AM, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 19/07/2018 05:59, Kyotaro HORIGUCHI wrote: >> My result is that we cannot disable recycling perfectly just by >> setting min/max_wal_size. > > Maybe the behavior of min_wal_size should be rethought? Elsewhere in > this thread, there was also a complaint that max_wal_size isn't actually > a max. It seems like there might be some interest in making these > settings more accurate. > > I mean, what is the point of the min_wal_size setting if not controlling > this very thing?
See the logic in XLOGfileslop(). The number of segments that the server recycles (by renaming) after a checkpoint is bounded to not less than min_wal_size and not more than max_wal_size, but the actual value fluctuates between those two extremes based on the number of segments the server believes will be required before the next checkpoint completes. Logically, min_wal_size = 0 would mean that the number of recycled segments could be as small as zero. However, what is being requested here is to force the number of recycled segments to never be larger than zero, which is different. As far as the log in XLOGfileslop() is concerned, that would correspond to max_wal_size = 0, not min_wal_size = 0. However, that's an impractical setting because max_wal_size is also used in other places, like CalculateCheckpointSegments(). In other words, min_wal_size = 0 logically means that we MIGHT NOT recycle any WAL segments, but the desired behavior here is that we DO NOT recycle any WAL segments. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
