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

From: Reid Thompson <reid(dot)thompson(at)crunchydata(dot)com>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Cc: reid(dot)thompson(at)crunchydata(dot)com
Subject: Re: Patch to address creation of PgStat* contexts with null parent context
Date: 2022-08-04 17:12:32
Message-ID: 96844dc69278a5414d2276fd9a2fbf2c08e58dd7.camel@crunchydata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)thompson(at)crunchydata(dot)com
www.crunchydata.com

Attachment Content-Type Size
002-address-creation-of-PgStat-contexts-with-null-parent-context.patch text/x-patch 446 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-08-04 17:49:06 Re: pg15b2: large objects lost on upgrade
Previous Message Andres Freund 2022-08-04 16:59:08 Re: pg15b2: large objects lost on upgrade