Re: libpq debug log

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Feb 21, 2019 at 7:52 PM Iwata, Aya <iwata(dot)aya(at)jp(dot)fujitsu(dot)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