From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: shared memory based stat collector (was: Sharing record typmods between backends) |
Date: | 2017-08-14 17:02:40 |
Message-ID: | 20170814170240.kd2pzkkbrdtiowi5@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmail(dot)com> wrote:
>
> > On Sun, Aug 13, 2017 at 9:59 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-08-14 17:06:48 | Re: shared memory based stat collector (was: Sharing record typmods between backends) |
Previous Message | Robert Haas | 2017-08-14 17:00:41 | Re: shared memory based stat collector (was: Sharing record typmods between backends) |