Re: libpq debug log

Поиск
Список
Период
Сортировка
От 'Alvaro Herrera'
Тема Re: libpq debug log
Дата
Msg-id 20210202142045.GA13771@alvherre.pgsql
обсуждение исходный текст
Ответ на RE: libpq debug log  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Ответы RE: libpq debug log  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Список pgsql-hackers
On 2021-Jan-29, tsunakawa.takay@fujitsu.com wrote:

> (30)
> +/*
> + * Deallocate FE/BE message tracking memory.  We only do this because
> + * FE message can grow arbitrarily large, and skip it in the initial state,
> + * because it's likely pointless.
> + */
> +void
> +pqTraceUninit(PGconn *conn)
> +{
> +    if (conn->fe_msg &&
> +        conn->fe_msg->num_fields != DEF_FE_MSGFIELDS)
> +    {
> +        free(conn->fe_msg);
> +        conn->fe_msg = NULL;
> +    }
> 
> What does the second if condition mean?  If it's not necessary, change the comment accordingly.

The rationale for that second condition is this: if the memory allocated
is the initial size, we don't free memory, because it would just be
allocated of the same size next time, and that size is not very big, so
it's not a big deal if we just let it be, so that it is reused if we
call PQtrace() again later.  However, if the allocated size is larger
than default, then it is possible that some previous tracing run has
enlarged the trace struct to a very large amount of memory, and we don't
want to leave that in place.

-- 
Álvaro Herrera       Valdivia, Chile



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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Typo in tablesync comment
Следующее
От: Victor Yegorov
Дата:
Сообщение: Re: New IndexAM API controlling index vacuum strategies