RE: libpq debug log - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: libpq debug log
Date
Msg-id TYAPR01MB2990FD222CCB8AE53B43DB2DFEBD0@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: libpq debug log  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Responses RE: libpq debug log  ("k.jamison@fujitsu.com" <k.jamison@fujitsu.com>)
List pgsql-hackers
First, some possibly major questions:


(23)
From: 'Alvaro Herrera' <alvherre@alvh.no-ip.org>
> 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.

What do you think about this suggestion?  I think this is reasonable, including moving PQtrace/PQuntrace to the new
file.

OTOH, fe-misc also has humble reasons to contain them.  One is that the file header comment is as follows, accepting
miscellaneousstuff.  Another is that although most functions in fe-misc.c are related to protocol data transmission and
receipt,several functions at the end of the file are already not related.
 

 *      fe-misc.c
 *
 *   DESCRIPTION
 *       miscellaneous useful functions


(24)
-void PQtrace(PGconn *conn, FILE *stream);
+void PQtrace(PGconn *conn, FILE *stream, bits32 flags);
 </synopsis>
      </para>
 
+     <para>
+      <literal>flags</literal> contains flag bits describing the operating mode
+      of tracing.  If <literal>(flags & TRACE_SUPPRESS_TIMESTAMPS)</literal> is
+      true, then timestamps are not printed with each message.
+     </para>

As I asked in the previous mail, I'm afraid we cannot change the signature of existing API functions.  If we want this
flagbits, we have to add something like PQtraceEx(), don't we?
 

The flag name differs between in the manual and in the source code:

+#define PQTRACE_SUPPRESS_TIMESTAMPS        (1 << 0)


P.S.
Also, please note this as:

> Also, why don't you try running the regression tests with a temporary modification to PQtrace() to output the trace
toa file?  The sole purpose is to confirm that this patch doesn't make the test crash (core dump).
 



Regards
Takayuki Tsunakawa


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Heap's backwards scan scans the incorrect pages with heap_setscanlimits()
Next
From: Pavel Stehule
Date:
Subject: Re: The mysterious pg_proc.protrftypes