Re: Creating a function for exposing memory usage of backend process

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: torikoshia <torikoshia@oss.nttdata.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-06-19T18:11:25Z
Lists: pgsql-hackers
On Wed, Jun 17, 2020 at 11:56 PM Fujii Masao
<masao.fujii@oss.nttdata.com> wrote:
> > As a first step, to deal with (3) I'd like to add
> > pg_stat_get_backend_memory_context() which target is limited to the
> > local backend process.
>
> +1

+1 from me, too. Something that exposed this via shared memory would
be quite useful, and there are other things we'd like to expose
similarly, such as the plan(s) from the running queries, or even just
the untruncated query string(s). I'd like to have a good
infrastructure for that sort of thing, but I think it's quite tricky
to do properly. You need a variable-size chunk of shared memory, so
probably it has to use DSM somehow, and you need to update it as
things change, but if you update it too frequently performance will
stink. If you ping processes to do the updates, how do you know when
they've completed them, and what happens if they don't respond in a
timely fashion? These are probably all solvable problems, but I don't
think they are very easy ones.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



Commits

  1. Add regression test for pg_backend_memory_contexts.

  2. Move codes for pg_backend_memory_contexts from mmgr/mcxt.c to adt/mcxtfuncs.c.

  3. Prevent non-superusers from reading pg_backend_memory_contexts, by default.

  4. Add pg_backend_memory_contexts system view.

  5. Fix yet another issue with step generation in partition pruning.