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
-
Add memory context identifier to portal context
- 94c1f9ba11d1 11.0 landed
-
Rename MemoryContextCopySetIdentifier() for clarity
- bbca77623fb5 11.0 landed
-
Allow memory contexts to have both fixed and variable ident strings.
- 442accc3fe0c 11.0 landed
-
Rethink MemoryContext creation to improve performance.
- 9fa6f00b1308 11.0 cited