Re: libpq debug log - Mailing list pgsql-hackers

From Yugo Nagata
Subject Re: libpq debug log
Date
Msg-id 20180827215124.0cdb4d0cb99136b5a86b1d9f@sraoss.co.jp
Whole thread Raw
In response to libpq debug log  ("Iwata, Aya" <iwata.aya@jp.fujitsu.com>)
Responses RE: libpq debug log
List pgsql-hackers
On Fri, 24 Aug 2018 04:38:22 +0000
"Iwata, Aya" <iwata.aya@jp.fujitsu.com> wrote:

> Hi,
> 
> I'm going to propose libpq debug log for analysis of queries on the application side.
> I think that it is useful to determine whether the cause is on the application side or the server side when a slow
queryoccurs. 
 

Do you mean you want to monitor the protocol message exchange at
the client side to analyze performance issues, right?  Actually,
this might be useful to determin where is the problem, for example,
the client application, the backend PostgreSQL, or somewhere in the
network.

Such logging can be implemented in the application, but if libpq
provides the standard way, it would be helpful to resolve a problem
without modifying the application code.

> The provided information is "date and time" at which execution of processing is started, "query", "application side
processing",which is picked up information from PQtrace(), and "connection id", which is for uniquely identifying the
connection.
 

I couldn't image how this is like. Could you show us a sample of log lines
in your head?

> To collect the log, set the connection string or environment variable.
> - logdir or PGLOGDIR : directory where log file written
> - logsize or PGLOGSIZE : maximum log size

How we can specify the log file name?  What should happen if a file size
exceeds to PGLOGSIZE?

Regards,
-- 
Yugo Nagata <nagata@sraoss.co.jp>


pgsql-hackers by date:

Previous
From: Yugo Nagata
Date:
Subject: Re: pg_verify_checksums -d option (was: Re: pg_verify_checksums -roption)
Next
From: Stephen Frost
Date:
Subject: Re: pg_dump test instability