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

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: bdrouvot(at)amazon(dot)com
Cc: andres(at)anarazel(dot)de, 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-05 08:32:20
Message-ID: 20220905.173220.2184205169841086650.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Mon, 5 Sep 2022 08:52:44 +0200, "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com> wrote in
> Could using TopMemoryContext like in the attach be an option? (aka
> changing CacheMemoryContext by TopMemoryContext in the 3 places of
> interest): that would ensure the 3 pgStat* contexts to have a non NULL
> parent context.

Of course it works. The difference from what I last proposed is
whether we postpone creating the memory contexts until the first call
to pgstat_get_entry_ref(). 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.

I forgot about pgStatPendingContext, but it is sensible that we treat
it the same way to the other two.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2022-09-05 09:08:16 Re: pg15b3: recovery fails with wal prefetch enabled
Previous Message Daniel Gustafsson 2022-09-05 08:24:25 Re: Fix typo function circle_same (src/backend/utils/adt/geo_ops.c)