Horton

RE: libpq debug log

tsunakawa.takay@fujitsu.com <tsunakawa.takay@fujitsu.com>

View thread View on postgr.es
From: "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>
To: 'Alvaro Herrera' <alvherre@alvh.no-ip.org>, "iwata.aya@fujitsu.com" <iwata.aya@fujitsu.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: "k.jamison@fujitsu.com" <k.jamison@fujitsu.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2021-02-04T01:18:25Z
Lists: pgsql-hackers 
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
> I'm pretty sure I named the flag PQTRACE_SUPPRESS_TIMESTAMP (and I
> prefer SUPPRESS to NOOUTPUT), because the idea is that the timestamp is
> printed by default.  I think that's the sensible decision: applications
> prefer to have timestamps, even if there's a tiny bit of overhead.  We
> don't want to force them to pass a flag for that.  We only want the
> no-timestamp behavior in order to be able to use it for libpq internal
> testing.

Agreed.  It makes sense to print timestamps by default because this feature will be used to diagnose slowness outside the database server.  (I misunderstood the motivation to introduce the flag).




Regards
Takayuki Tsunakawa

Commits

  1. Rename PQtraceSetFlags() to PQsetTraceFlags().

  2. Suppress length of Notice/Error msgs in PQtrace regress mode

  3. Strip file names reported in error messages on Windows, too.

  4. Fix setvbuf()-induced crash in libpq_pipeline

  5. libpq_pipeline: Must strdup(optarg) to avoid crash

  6. Remove setvbuf() call from PQtrace()

  7. Initialize conn->Pfdebug to NULL when creating a connection

  8. Disable force_parallel_mode in libpq_pipeline

  9. libpq_pipeline: add PQtrace() support and tests

  10. Improve PQtrace() output format

  11. Re-simplify management of inStart in pqParseInput3's subroutines.