Re: shared-memory based stats collector

At Thu, 11 Mar 2021 19:22:57 -0800, Andres Freund <andres(at)anarazel(dot)de> wrote in
> Hi,
>
> On 2021-03-10 20:26:56 -0800, Andres Freund wrote:
> > > +static void
> > > +attach_shared_stats(void)
> > > +{
> > > + MemoryContext oldcontext;
> >
> > > + /*
> > > + * The first attacher backend may still reading the stats file, or the
> > > + * last detacher may writing it. Wait for the work to finish.
> > > + */
> >
> > I still believe this kind of approach is too complicated, and we should
> > simply not do any of this "first attacher" business. Instead read it in
> > the startup process or such.
>
> I started changing the patch to address my complaints. I'll try to do
> it as an incremental patch ontop of your 0004, but it might become too
> unwieldy. Not planning to touch other patches for now (and would be

Sorry for bothering you by that but thank you very much for the
labor. Actually the startup is always the first and lonely attacher
but the last detacher may be any of checkpointer, archiver or
walsender. And I was reluctant to add new stats-mechanism initializer
other than attach_sahred_stats. Those are the reason (to me) for the
*first* attacher mechanism.

However, surely we can separate the "first attacher business" as a
separate function. And maybe the "fear" backing the complexity is
groundless and such overlap might not actually happen.

The current mechanism repeats read->write process twice while starting
up server, which is annoyance to me.

> happy if the first few were committed). I do think we'll have to
> split 0004 a bit - it's just too large to commit as is, I think.

Deeply agreed. 0004 is too large and quite confusive to diff. It is
always tough to resolve a conflict:(

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center