Re: libpq debug log - Mailing list pgsql-hackers

From 'Alvaro Herrera'
Subject Re: libpq debug log
Date
Msg-id 20210202142045.GA13771@alvherre.pgsql
Whole thread Raw
In response to RE: libpq debug log  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Responses RE: libpq debug log  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
List 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 by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Typo in tablesync comment
Next
From: Victor Yegorov
Date:
Subject: Re: New IndexAM API controlling index vacuum strategies