From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | zmlpostgres(at)gmail(dot)com |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, reid(dot)thompson(at)crunchydata(dot)com |
Subject: | Re: Patch to address creation of PgStat* contexts with null parent context |
Date: | 2022-07-29 02:53:56 |
Message-ID: | 20220729.115356.1101005842809628822.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Thu, 28 Jul 2022 22:03:13 +0800, Zhang Mingli <zmlpostgres(at)gmail(dot)com> wrote in
> Hi,
>
> On Jul 28, 2022, 21:30 +0800, Reid Thompson <reid(dot)thompson(at)crunchydata(dot)com>, wrote:
> > Attached is a patch to address this.
Good Catch!
> Codes seem good, my question is:
>
> Do auto vacuum processes need CacheMemoryContext?
pgstat_report_vacuum requires it. Startup process doesn't seem to use
pgstats while recovery proceeding but requires the context only at
termination...
> Is it designed not to create CacheMemoryContext in such processes?
>
> If so, we’d better use TopMemoryContext in such processes.
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(). Or couldn't we create the
all three contexts in the function, instead of calling
pgstat_setup_memcxt() on-the fly?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2022-07-29 02:56:12 | Re: Functions 'is_publishable_class' and 'is_publishable_relation' should stay together. |
Previous Message | houzj.fnst@fujitsu.com | 2022-07-29 01:55:38 | RE: Functions 'is_publishable_class' and 'is_publishable_relation' should stay together. |