Re: libpq debug log

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: tsunakawa.takay@fujitsu.com
Cc: iwata.aya@fujitsu.com, k.jamison@fujitsu.com, alvherre@alvh.no-ip.org, pgsql-hackers@lists.postgresql.org
Date: 2021-02-26T08:30:32Z
Lists: pgsql-hackers
At Fri, 26 Feb 2021 16:12:39 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in 
> This inhibits logCursor being updated. What is worse, I find that
> logCursor movement is quite dubious.

Using (inCursor - inStart) as logCursor doesn't work correctly if
tracing state desyncs.  Once desync happens inStart can be moved at
the timing that the tracing code doesn't expect. This requires (as I
mentioned upthread) pqReadData to actively reset logCursor, though.

logCursor should move when bytes are fed to the tracing functoins even
when theyare the last bytes of a message.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



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.