Re: [HACKERS] shared memory based stat collector (was: Sharingrecord typmods between backends)
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] shared memory based stat collector (was: Sharingrecord typmods between backends) |
Дата | |
Msg-id | 20170814170240.kd2pzkkbrdtiowi5@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] shared memory based stat collector (was: Sharing recordtypmods between backends) (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: [HACKERS] shared memory based stat collector (was: Sharing recordtypmods between backends)
|
Список | pgsql-hackers |
On 2017-08-14 18:57:39 +0200, Magnus Hagander wrote: > On Mon, Aug 14, 2017 at 5:46 PM, Robert Haas <robertmhaas@gmail.com> wrote: > > > 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. 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
В списке pgsql-hackers по дате отправления: