Re: Patch to address creation of PgStat* contexts with null parent context

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: andres(at)anarazel(dot)de
Cc: bdrouvot(at)amazon(dot)com, reid(dot)thompson(at)crunchydata(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Patch to address creation of PgStat* contexts with null parent context
Date: 2022-09-06 05:53:07
Message-ID: 20220906.145307.111469350873087363.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(It seems to me I overlooked some mails.. sorry.)

At Mon, 5 Sep 2022 15:47:37 -0700, Andres Freund <andres(at)anarazel(dot)de> wrote in
> On 2022-09-05 17:32:20 +0900, Kyotaro Horiguchi wrote:
> > The rationale of creating them at pgstat_attach_shmem is that anyway once
> > pgstat_attach_shmem is called, the process fainally creates the contexts at
> > the end of the process, and (I think) it's simpler that we don't do if()
> > check at every pgstat_get_entry_ref() call.
>
> But that's not true, as pointed out here:
> https://postgr.es/m/20220808192020.nc556tlgcp66fdgw%40awork3.anarazel.de
>
> Nor does it make sense to reserve memory for the entire lifetime of a process
> just because we might need it for a split second at the end.

Yeah, that's the most convincing argument aginst it.

At Mon, 5 Sep 2022 14:46:55 +0200, "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com> wrote in
> Looks like that both approaches have their pros and cons. I'm tempted
> to vote +1 on "just changing" the parent context to TopMemoryContext
> and not changing the allocations locations.

Yeah. It is safe more than anything and we don't have a problem there.

So, I'm fine with just replacing the parent context at the three places.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2022-09-06 05:53:36 Re: more descriptive message for process termination due to max_slot_wal_keep_size
Previous Message Peter Eisentraut 2022-09-06 05:44:13 Re: [PATCH] Renumber confusing value for GUC_UNIT_BYTE