Re: shared-memory based stats collector - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: shared-memory based stats collector
Date
Msg-id 8e041a34a70ae5d44cb10a7e516308e2f6d1b651.camel@2ndquadrant.com
Whole thread Raw
In response to Re: shared-memory based stats collector  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: shared-memory based stats collector
List pgsql-hackers
On Mon, 2018-11-12 at 20:10 +0900, Kyotaro HORIGUCHI wrote:
> At Fri, 9 Nov 2018 14:16:31 +0100, Tomas Vondra <
> tomas.vondra@2ndquadrant.com> wrote in <
> 803f2d96-3b4b-f357-9a2e-45443212f13d@2ndquadrant.com>
> > 
> > 
> > On 11/9/18 9:33 AM, Kyotaro HORIGUCHI wrote:
> > > Hello. This is rebased version.
> > > At Thu, 8 Nov 2018 16:06:49 +0100, Tomas Vondra
> > > <tomas.vondra@2ndquadrant.com> wrote in
> > > <de249c3f-79c9-b75c-79a3-5e2d008548a8@2ndquadrant.com>
> > >> However a quite a few extensions in contrib seem are broken now.
> It
> > >> seems fixing it is as simple as including the new bestatus.h
> next to
> > >> pgstat.h.
> > > The additional 0009 does that.
> > > 
> > 
> > That does fix it, indeed. But the break happens in 0003, so that's
> > where the fixes should be moved - I've tried to simply apply 0009
> > right after 0003, but that does not seem to work because bestatus.h
> > does not exist at that point yet :-/
> 
> Sorry, I misunderstood you. The real reason for breaking 0003 as
> you saw was the result I just removed PG_STAT_TMP_DIR. 0005 fixes
> that later. I (half-intentionally) didin't keep soundness of the
> source tree at v8-0003 and v8-0008.
> 
> > The current split into 8 parts seems quite sensible to me, i.e.
> that's
> > how it might get committed eventually. That however means each part
> > needs to be correct on it's own (hence fixes in 0009 are a
> problem).
> 
> Thanks. I neatended up the patchset so that individual patch
> keeps source buildable and doesn't break programs' behaviors.
> 

OK, thanks. I'll take a look. I also plan to do much more testing, both
for correctness and performance - it's quite piece of functionality.

If everything goes well I'd like to get this committed by the end of
January CF (with some of the initial parts in this CF, possibly).


regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: spurious(?) warnings in archive recovery
Next
From: "Bossart, Nathan"
Date:
Subject: Re: Make description of heap records more talkative for flags