Re: shared-memory based stats collector

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: andres(at)anarazel(dot)de
Cc: masao(dot)fujii(at)oss(dot)nttdata(dot)com, gkokolatos(at)protonmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: shared-memory based stats collector
Date: 2021-03-11 04:42:27
Message-ID: 20210311.134227.1280084378060460266.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Wed, 10 Mar 2021 19:21:00 -0800, Andres Freund <andres(at)anarazel(dot)de> wrote in
> Hi,
>
> Two minor nits:

Thanks for the comments!

> On 2021-03-10 21:47:51 +0900, Fujii Masao wrote:
> > +/* Shared memory area for archiver process */
> > +typedef struct PgArchData
> > +{
> > + Latch *latch; /* latch to wake the archiver up */
> > + slock_t mutex; /* locks this struct */
> > +} PgArchData;
> > +
>
> It doesn't really matter, but it'd be pretty trivial to avoid needing a
> spinlock for this kind of thing. Just store the pgprocno of the archiver
> in PgArchData.

Looks promising.

> While getting rid of the spinlock doesn't seem like a huge win, it does
> seem nicer that we'd automatically have a way to find data about the
> archiver (e.g. pid).

PGPROC GetAuxProcessInfo(AuxProcType type)?

> > * checkpointer to exit as well, otherwise not. The archiver, stats,
> > * and syslogger processes are disregarded since they are not
> > * connected to shared memory; we also disregard dead_end children
> > * here. Walsenders are also disregarded, they will be terminated
> > * later after writing the checkpoint record, like the archiver
> > * process.
> > */
>
> This comment in PostmasterStateMachine() is outdated now.

Right. Will fix a bit later.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuro Yamada 2021-03-11 06:10:04 Re: Huge memory consumption on partitioned table with FKs
Previous Message Dilip Kumar 2021-03-11 04:37:30 Re: [HACKERS] Custom compression methods