Date: Fri, 22 Jan 2021 10:38:20 -0300
From: 'Alvaro Herrera' <alvherre@alvh.no-ip.org>
To: "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>
Cc: "iwata.aya@fujitsu.com" <iwata.aya@fujitsu.com>,
	"'pgsql-hackers@lists.postgresql.org'" <pgsql-hackers@lists.postgresql.org>
Subject: Re: libpq debug log
Message-ID: <20210122133820.GA12162@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <TYAPR01MB2990E464C5E77200D867AFB1FEA00@TYAPR01MB2990.jpnprd01.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

Hello, just two quick comments on this,

On 2021-Jan-22, tsunakawa.takay@fujitsu.com wrote:

> From: Alvaro Herrera <alvherre@alvh.no-ip.org>
> > That's true, but it'd require that we move PQtrace() to fe-misc.c, because
> > pqTraceInit() uses definitions that are private to that file.
> 
> Ah, that was the reason for separation.  Then, I'm fine with either
> keeping the separation, or integrating the two functions in fe-misc.c
> with PQuntrace() being also there.  I kind of think the latter is
> better, because of code readability and, because tracing facility is
> not a connection-related reature so categorizing it as "misc" feels
> natural.

Maybe we can create a new file specifically for this to avoid mixing
unrelated stuff in fe-misc.c -- say fe-trace.c where all this new
tracing stuff goes.

> > The point is to be able to cope with a connection that calls PQtrace() multiple
> > times, with or without an intervening PQuntrace().
> > We'd make no friends if we made PQtrace() crash, or leak memory if called a
> > second time ...
> 
> HEAD's PQtrace() always call PQuntrace() and then re-initialize from
> scratch.  So, if we keep that flow, the user can call PQtrace()
> multiple in a row.

Oh, of course.

-- 
Álvaro Herrera       Valdivia, Chile
"No necesitamos banderas
 No reconocemos fronteras"                  (Jorge González)