Re: Enhancing Memory Context Statistics Reporting
| От | Daniel Gustafsson |
|---|---|
| Тема | Re: Enhancing Memory Context Statistics Reporting |
| Дата | |
| Msg-id | 43D5E807-AC37-4136-85FD-15B6F1BEF840@yesql.se обсуждение исходный текст |
| Ответ на | Re: Enhancing Memory Context Statistics Reporting (Rahila Syed <rahilasyed90@gmail.com>) |
| Список | pgsql-hackers |
> On 9 Jan 2026, at 12:22, Rahila Syed <rahilasyed90@gmail.com> wrote: > After further discussion and reviewing Robert's email[1] on this topic, a safer solution > is to avoid running ProcessGetMemoryContextInterrupt during an aborted transaction. > This should help prevent additional errors when the transaction is already in error handling > state. Also, reporting memory context statistics from an aborting transaction won't > be very useful as some of that memory usage won't be valid after abort completes. +1, I think was the right call to make. > Attached is the updated patch that addresses this. A few small comments on v47: +static const char *ContextTypeToString(NodeTag type); I think context_type_to_string() would be a better name on this internal function to model it closer to the existing int_list_to_array(). Personally I would also place it before its first use to avoid the prototype, but that's personal preference. +static void +memstats_dsa_cleanup(char *key) This function warrants a documentation comment describing when it should be used safely. + memstats_dsa_cleanup(key); + memstats_client_key_reset(procNumber); + ConditionVariableCancelSleep(); + PG_RETURN_NULL(); I think we should notify the user in these two timeout cases, why not adding an ereport(NOTICE, "request for memory context statistics timed out")); or something with a better wording than that. + Size sz = 0; + Size TotalProcs = 0; + + TotalProcs = add_size(TotalProcs, NUM_AUXILIARY_PROCS); + TotalProcs = add_size(TotalProcs, MaxBackends); + sz = add_size(sz, mul_size(TotalProcs, sizeof(int))); + + return sz As we discussed off-list, the call to add_size() call can be omitted as it won't affect the calculation. +# Copyright (c) 2025, PostgreSQL Global Development Group Here, and possibly elsewhere, it should say 2026 instead I think. -- Daniel Gustafsson
В списке pgsql-hackers по дате отправления: