Horton

Re: libpq debug log

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "Iwata, Aya" <iwata.aya@jp.fujitsu.com>, "Jamison, Kirk" <k.jamison@jp.fujitsu.com>, "Nagaura, Ryohei" <nagaura.ryohei@jp.fujitsu.com>, Jacob Champion <pchampion@pivotal.io>, Jim Doty <jdoty@pivotal.io>, PostgreSQL mailing lists <pgsql-hackers@postgresql.org>, "nagata@sraoss.co.jp" <nagata@sraoss.co.jp>, Haribabu Kommi <kommi.haribabu@gmail.com>, Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Date: 2019-02-22T18:51:56Z
Lists: pgsql-hackers 
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Feb 21, 2019 at 7:52 PM Iwata, Aya <iwata.aya@jp.fujitsu.com> wrote:
>> Aside from problems with my current documentation which I will fix,
>> could you explain more detail about the problem of the design?

> We already have a PQtrace() facility that could be improved, and it
> has been previously suggested that you work on improving this facility
> rather than inventing something new.  I still think that's a good
> idea.

Me too.  PQtrace as currently constituted might be helpful for debugging
libpq itself, but it's nigh useless for any higher-level purpose.  I'd
gladly toss overboard any hypothetical use-case for what it does now,
in favor of having something that dumps stuff at the logical level of
messages.  (It's not even very consistent, because somebody did add a
more-or-less-message-level printout to pqSaveParameterStatus, which
I believe is duplicative of what fe-misc.c will print about the
same interaction at the byte level.)

> Instead you've created a second way of producing similar
> information, and then coupled it to very specific ideas about how that
> information should be logged: it is triggered by new libpq parameters,
> there is log rotation logic, etc.  Those might not be right for
> everyone, and there's no flexibility in the mechanism.

Good point.  To the extent that people want any of that, they'd probably
want to have application control over it.  Maybe, in addition to
PQtrace(FILE *) that'd just dump to a stdio stream, there should be a way
to create a callback similar to a notice-message hook, and let the
application implement such features in a custom callback.

> I am not sure that it's a good idea to have facilities that write to
> the local filesystem that can be triggered by libpq parameters.

Oy.  That seems like a *very* serious objection.  I agree with Robert's
thought that it'd be better to insist on application involvement in
enabling trace output.

			regards, tom lane

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.