Re: libpq debug log - Mailing list pgsql-hackers

From 'Alvaro Herrera'
Subject Re: libpq debug log
Date
Msg-id 20210122133820.GA12162@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  ("iwata.aya@fujitsu.com" <iwata.aya@fujitsu.com>)
List pgsql-hackers
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)



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: pg_rewind copies
Next
From: Alvaro Herrera
Date:
Subject: Re: LogwrtResult contended spinlock