Re: shared-memory based stats collector

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: andres(at)anarazel(dot)de
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, alvherre(at)2ndquadrant(dot)com, michael(at)paquier(dot)xyz, thomas(dot)munro(at)gmail(dot)com, tomas(dot)vondra(at)2ndquadrant(dot)com, a(dot)zakirov(at)postgrespro(dot)ru, ah(at)cybertec(dot)at, magnus(at)hagander(dot)net, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: shared-memory based stats collector
Date: 2020-03-10 06:11:21
Message-ID: 20200310.151121.615486127876459186.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Mon, 9 Mar 2020 20:34:20 -0700, Andres Freund <andres(at)anarazel(dot)de> wrote in
> On 2020-03-10 12:27:25 +0900, Kyotaro Horiguchi wrote:
> > That's true, but I have the same concern with Tom. The archive bacame
> > too-tightly linked with other processes than actual relation.
>
> What's the problem here? We have a number of helper processes
> (checkpointer, bgwriter) that are attached to shared memory, and it's
> not a problem.

That theoretically raises the chance of server-crash by a small amount
of probability. But, yes, it's absurd to prmise that archiver process
crashes.

> > We may need the second static shared memory segment apart from the
> > current one.
>
> That seems absurd to me. Solving a non-problem by introducing complex
> new infrastructure.

Ok. I think I must be worrying too much.

Thanks for the suggestion.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-03-10 06:17:23 Re: Crash by targetted recovery
Previous Message Kyotaro Horiguchi 2020-03-10 05:59:00 Re: Crash by targetted recovery