RE: libpq debug log

Поиск
Список
Период
Сортировка
От tsunakawa.takay@fujitsu.com
Тема RE: libpq debug log
Дата
Msg-id TYAPR01MB2990ED8D66CAB2CC0CCD25C4FE8B9@TYAPR01MB2990.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на RE: libpq debug log  ("iwata.aya@fujitsu.com" <iwata.aya@fujitsu.com>)
Ответы RE: libpq debug log  ("iwata.aya@fujitsu.com" <iwata.aya@fujitsu.com>)
Список pgsql-hackers
(48)
 <synopsis>
 void PQtrace(PGconn *conn, FILE *stream);
 </synopsis>
      </para>

+     <para>
+      Calls <function>PQtraceSetFlags</function> to output with or without a timestamp.
+     </para>
+
      <note>

Why is this necessary?  Even if you decide to remove this change, can you share your idea on why you added this just in
case?


(49)
+      Determine to output tracing with or without a timestamp to a debugging file stream.

The description should be the overall functionality of this function considering the future additions of flags.
Somethinglike: 

Controls the tracing behavior of client/server communication.

+      then timestamp is not printed with each message. The default is output with timestamp.

The default value for flags argument (0) should be described here.

Also, it should be added that PQsetTraceFlags() can be called before or after the PQtrace() call.


(50)
I'd like you to consider skipLogging again, because it seems that such a variable is for the logging machinery to
controlstate transitions internally in fe-logging.c. 
What I'm concerned is that those who modify libpq have to be aware of skipLogging and would fail to handle it.


(51)
>> +typedef enum PGLogState
>> +{
>>
>> This is libpq-logging.c internal type. It is not needed to be exposed.

> I fixed it.

How did you fix it?  The typedef is still in .h file.  It should be in .h, shouldn't it?  Houw about the other
typedefs?



I won't comment on the other stuff on function naming.


Regards
Takayuki Tsunakawa





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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: WIP: WAL prefetch (another approach)
Следующее
От: Greg Nancarrow
Дата:
Сообщение: Re: Parallel INSERT (INTO ... SELECT ...)