Re: Backend memory dump analysis

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Backend memory dump analysis
Дата
Msg-id 2035.1521832363@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Backend memory dump analysis  (Andres Freund <andres@anarazel.de>)
Ответы Re: Backend memory dump analysis
Re: Backend memory dump analysis
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2018-03-23 14:33:25 -0400, Tom Lane wrote:
>> +   MemoryContextSetIdentifier(func_cxt, function->fn_signature);
>> 
>> 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.

Well, in the cases I'm thinking of at the moment, there's no handy Node
to point at, just module-private structs like PLpgSQL_function.  So doing
anything like that would add nonzero overhead to construct something.
Not sure we want to pay that.  There's also the fact that we don't want
MemoryContextStats doing anything very complicated, because of the risk of
failure and the likelihood that any attempt to palloc would fail (if we're
there because we're up against OOM already).

>> 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.

I'll put together a draft patch.

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: ppc64le support in 9.3 branch?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Backend memory dump analysis