Re: libpq debug log

From: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
To: "Iwata, Aya" <iwata(dot)aya(at)jp(dot)fujitsu(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: libpq debug log
Date: 2018-08-27 12:51:24
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Fri, 24 Aug 2018 04:38:22 +0000
"Iwata, Aya" <iwata(dot)aya(at)jp(dot)fujitsu(dot)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 query occurs.

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

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?

Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2018-08-27 13:35:21 Re: pg_dump test instability
Previous Message Yugo Nagata 2018-08-27 12:05:33 Re: pg_verify_checksums -d option (was: Re: pg_verify_checksums -r option)