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