On Sun, Aug 13, 2017 at 9:59 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> b) I think our tendency to dump all stats whenever we crash isn't really >> tenable, given how autovacuum etc are tied to them. > > Eh, maybe. I don't think crashes are really so common on production > systems. As developers we have an inflated view of their frequency ;-)
From a stats perspective I think the crash problem is the small problem. The big problem is we nuke them on replication promotion and we nuke them on PITR. If we solve those two, I'm pretty sure we would also solve the on-crash more or less in the same thing.
Without taking a position on the point under debate, AFAIK it wouldn't be technically complex either under our current architecture or the proposed new one to dump out a new permanent stats file every 10 minutes or so. So if there is an issue here I think it might not be very hard to fix, whatever else we do.
I started working on that patch at some point, I think I have a rotting branch somewhere. That part was indeed fairly easy.
I got stalled when I feature-crept myself by realizing I wanted it snapshotted to WAL so it could fix the PITR and replication issues. And then properly bogged down when I realized that on the standby I'd want *both* the stats from the standby (while it's running) and the stats from the master (after switchover).
