On Tue, Nov 22, 2016 at 10:26 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote:
> Andres Freund wrote: > > On 2016-11-22 16:15:58 -0500, Tom Lane wrote: > > > > Maybe a workable compromise would be to leave the file present, and > have > > > the stats collector re-write it every (say) five minutes. Then I'd be > > > okay with having an immediate shutdown skip writing the file; you'd be > > > losing up to five minutes' worth of activity, but not going completely > > > nuts. So the stats collector's normal activities would include writing > > > the temp file on-demand and the permanent file on a timed cycle. > > > > > > The other components of the fix (deleting on PITR rewind or stats > > > collector crash) would remain the same. > > +1 > > > It could even make sense to WAL log the contents of the stats file at > > checkpoint (or similar) time. Then it'd be sane after crash recovery, > > including starting from an old base backup. Loosing the information > > about what to vacuum / analyze after a failover is quite problematic... > > An idea worth considering. This would also mean the file is valid in a > standby -- the lack of the file is currently a problem if you promote > the standby, as I recall. But the file is perhaps too large to write to > WAL on every checkpoint. > There's also the consideration of what to do with stats *on the standby*. If we WAL log the stats file, then when it replays onthe standby, the stats there will be overwritten. And stats like number of index vs seq scans on the standby are still interesting and would be lost. That's not to say that I don't agree with the issues of failover vs autovacuum. But let's try to find a way that doesn't hurt other things to get there. But that could just be part of how we deal with the replay of it. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
