Re: Patch to address creation of PgStat* contexts with null parent context - Mailing list pgsql-hackers

From Reid Thompson
Subject Re: Patch to address creation of PgStat* contexts with null parent context
Date
Msg-id 96844dc69278a5414d2276fd9a2fbf2c08e58dd7.camel@crunchydata.com
Whole thread Raw
In response to Re: Patch to address creation of PgStat* contexts with null parent context  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Patch to address creation of PgStat* contexts with null parent context
List pgsql-hackers
On Fri, 2022-07-29 at 11:53 +0900, Kyotaro Horiguchi wrote:
>
> That makes the memorycontext-tree structure unstable because
> CacheMemoryContext can be created on-the-fly.
>
> Honestly I don't like to call CreateCacheMemoryContext in the two
> functions on-the-fly.  Since every process that calls
> pgstat_initialize() necessarily calls pgstat_setup_memcxt() at latest
> at process termination, I think we can create at least
> CacheMemoryContext in pgstat_initialize().

Attached is a patch creating CacheMemoryContext() in pgstat_initialize()
rather than the two previous patch locations.

> Or couldn't we create the
> all three contexts in the function, instead of calling
> pgstat_setup_memcxt() on-the fly?

You note that that pgstat_setup_memcxt() is called at latest at process
termination -- was the intent to hold off on requesting memory for these
two contexts until it was needed?

> regards.
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center


--
Reid Thompson
Senior Software Engineer
Crunchy Data, Inc.

reid.thompson@crunchydata.com
www.crunchydata.com




Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg15b2: large objects lost on upgrade
Next
From: Tom Lane
Date:
Subject: Re: pg15b2: large objects lost on upgrade