On 2017-08-14 18:57:39 +0200, Magnus Hagander wrote: > On Mon, Aug 14, 2017 at 5:46 PM, Robert Haas <robertmh...@gmail.com> wrote: > > > On Sun, Aug 13, 2017 at 9:59 PM, Tom Lane <t...@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.
I don't think they're that rare, but the others are problems too. Unfortunately I think changing that is a bit more complicated, given that some stats are actually updated on standbys. I previously thought that an option to occasionally WAL log the stats file would be useful (e.g. just before a checkpoint). That'd make them persistent, and available on the standby. But that'd still require somehow dealing with stats being produced on the standby - I presume we'd need multiple stats files and provide functions for merging them. It'd be good if we somehow could figure out a way to WAL log the stats data in a way that's consistent, i.e. doesn't contain data about dumped relations. But I don't quite see how... > > 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). Hah, indeed. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers