On 2016-11-22 16:15:58 -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > Well, the problem is that the stats data is not on disk while the system
> > is in operation, as far as I recall -- it's only in the collector's
> > local memory. On shutdown we tell it to write it down to a file, and on
> > startup we tell it to read it from the file and then delete it. I think
> > the rationale for this is to avoid leaving a file with stale data on
> > disk while the system is running.
>
> 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.
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...
Andres
