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

Hi,

I think this is an incredibly useful feature.

On 2020-07-07 22:02:10 +0900, torikoshia wrote:
> > There can be multiple memory contexts with the same name. So I'm afraid
> > that it's difficult to identify the actual parent memory context from
> > this
> > "parent" column. This is ok when logging memory contexts by calling
> > MemoryContextStats() via gdb. Because child memory contexts are printed
> > just under their parent, with indents. But this doesn't work in the
> > view.
> > To identify the actual parent memory or calculate the memory contexts
> > tree
> > from the view, we might need to assign unique ID to each memory context
> > and display it. But IMO this is overkill. So I'm fine with current
> > "parent"
> > column. Thought? Do you have any better idea?
>
> Indeed.
> I also feel it's not usual to assign a unique ID, which
> can vary every time the view displayed.

Hm. I wonder if we just could include the address of the context
itself. There might be reasons not to do so (e.g. security concerns
about leaked pointers making attacks easier), but I think it's worth
considering.

> We show each context using a recursive function and this is
> a kind of depth-first search. So, as far as I understand,
> we can identify its parent using both the "parent" column
> and the order of the rows.
>
> Documenting these things may worth for who want to identify
> the relation between parents and children.
>
> Of course, in the relational model, the order of relation
> does not have meaning so it's also unusual in this sense..

It makes it pretty hard to write summarizing queries, so I am not a huge
fan of just relying on the order.

> +/*
> + * PutMemoryContextsStatsTupleStore
> + * One recursion level for pg_get_backend_memory_contexts.
> + */
> +static void
> +PutMemoryContextsStatsTupleStore(Tuplestorestate *tupstore,
> + TupleDesc tupdesc, MemoryContext context,
> + MemoryContext parent, int level)
> +{
> +#define PG_GET_BACKEND_MEMORY_CONTEXTS_COLS 9
> + Datum values[PG_GET_BACKEND_MEMORY_CONTEXTS_COLS];
> + bool nulls[PG_GET_BACKEND_MEMORY_CONTEXTS_COLS];
> + MemoryContextCounters stat;
> + MemoryContext child;
> + const char *name = context->name;
> + const char *ident = context->ident;
> +
> + if (context == NULL)
> + return;
> +
> + /*
> + * To be consistent with logging output, we label dynahash contexts
> + * with just the hash table name as with MemoryContextStatsPrint().
> + */
> + if (ident && strcmp(name, "dynahash") == 0)
> + {
> + name = ident;
> + ident = NULL;
> + }
> +
> + /* Examine the context itself */
> + memset(&stat, 0, sizeof(stat));
> + (*context->methods->stats) (context, NULL, (void *) &level, &stat);
> +
> + memset(values, 0, sizeof(values));
> + memset(nulls, 0, sizeof(nulls));
> +
> + values[0] = CStringGetTextDatum(name);
> +
> + if (ident)
> + {
> + int idlen = strlen(ident);
> + char clipped_ident[MEMORY_CONTEXT_IDENT_DISPLAY_SIZE];
> +
> + /*
> + * Some identifiers such as SQL query string can be very long,
> + * truncate oversize identifiers.
> + */
> + if (idlen >= MEMORY_CONTEXT_IDENT_DISPLAY_SIZE)
> + idlen = pg_mbcliplen(ident, idlen, MEMORY_CONTEXT_IDENT_DISPLAY_SIZE - 1);
> +

Why?

Greetings,

Andres Freund