Re: Backend memory dump analysis

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Vladimir Sitnikov <sitnikov.vladimir@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2018-03-23T19:01:41Z
Lists: pgsql-hackers
Hi,

On 2018-03-23 14:33:25 -0400, Tom Lane wrote:
>     func_cxt = AllocSetContextCreate(TopMemoryContext,
>                                      "PL/pgSQL function context",
>                                      ALLOCSET_DEFAULT_SIZES);
>     plpgsql_compile_tmp_cxt = MemoryContextSwitchTo(func_cxt);
> 
>     function->fn_signature = format_procedure(fcinfo->flinfo->fn_oid);
> +   MemoryContextSetIdentifier(func_cxt, function->fn_signature);
>     function->fn_oid = fcinfo->flinfo->fn_oid;
>     function->fn_xmin = HeapTupleHeaderGetRawXmin(procTup->t_data);
> 
> This would cost an extra char * field in struct MemoryContextData,
> which is slightly annoying but it doesn't exactly seem like a killer.
> Then the memory stats dump code would just need to know to print this
> field if it isn't NULL.

That's not a bad idea. How about storing a Node* instead of a char*?
Then we could have MemoryContextStats etc support digging out details
for a few types, without having to generate strings at runtime.

> If we wanted to do this I'd suggest sneaking it into v11, so that
> if people have to adapt their code because of 9fa6f00b1 breaking
> usages with nonconstant context names, they have a solution to turn to
> immediately rather than having to change things again in v12.

Yea, that'd make sense.

Greetings,

Andres Freund


Commits

  1. Add memory context identifier to portal context

  2. Rename MemoryContextCopySetIdentifier() for clarity

  3. Allow memory contexts to have both fixed and variable ident strings.

  4. Rethink MemoryContext creation to improve performance.