On 2014-01-24 22:31:17 +0900, MauMau wrote: > From: "Fujii Masao" <masao.fu...@gmail.com> > >On Wed, Jan 22, 2014 at 6:37 AM, Heikki Linnakangas > >>>Thanks! The patch looks good to me. Attached is the updated version of > >>>the patch. I added the comments. > > Thank you very much. Your comment looks great. I tested some recovery > situations, and confirmed that WAL segments were kept/removed as intended. > I'll update the CommitFest entry with this patch.
You haven't updated the patches status so far, so I've now marked as returned feedback as several people voiced serious doubts about the approach. If that's not accurate please speak up. > >The problem is, we might not be able to perform restartpoints more > >aggressively > >even if we reduce checkpoint_timeout in the server under the archive > >recovery. > >Because the frequency of occurrence of restartpoints depends on not only > >that > >checkpoint_timeout but also the checkpoints which happened while the > >server > >was running. > > I haven't tried reducing checkpoint_timeout. Did you try reducing checkpoint_segments? As I pointed out, at least if standby_mode is enabled, it will also trigger checkpoints, independently from checkpoint_timeout. If the issue is that you're not using standby_mode (if so, why?), then the fix maybe is to make that apply to a wider range of situations. > I think we cannot take that > approach, because we cannot suggest appropriate checkpoint_timeout to users. > That is, what checkpoint_timeout setting can we suggest so that WAL doesn't > accumulate in pg_xlog/ more than 9.1? Well, <= 9.1's behaviour can lead to loss of a consistent database, so I don't think it's what we need to compare the current state to. 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
