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
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 |