RE: libpq debug log

From: "iwata(dot)aya(at)fujitsu(dot)com" <iwata(dot)aya(at)fujitsu(dot)com>
To: 'Álvaro Herrera' <alvherre(at)alvh(dot)no-ip(dot)org>, "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(at)fujitsu(dot)com>
Cc: "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>, 'Kyotaro Horiguchi' <horikyota(dot)ntt(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: libpq debug log
Date: 2021-02-26 02:52:49
Message-ID: TY2PR01MB19632DBEDEA0B0E6A18DF095EA9D9@TY2PR01MB1963.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro san,

Thank you very much for your updating and organizing this patch.

It appears that something is still wrong. I applied lipq pipeline v27 from [1] and ran src/test/modules/test_libpq/pipeline singlerow, after patching it to do PQtrace() after PQconn(). Below is the output I get from that. The noteworthy point is that "ParseComplete" messages appear multiple times for some reason ... but that's quite odd, because if I look at the network traffic with Wireshark I certainly do not see the ParseComplete message being sent three times.

I will search this cause. Please wait a minuets.
I thought I could avoid multiple such outputs by using conn->LogCursor…

Regards,
Aya Iwata
Fujitsu

From: Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Sent: Friday, February 26, 2021 2:49 AM
To: Iwata, Aya/岩田 彩 <iwata(dot)aya(at)fujitsu(dot)com>; Jamison, Kirk/ジャミソン カーク <k(dot)jamison(at)fujitsu(dot)com>
Cc: Tsunakawa, Takayuki/綱川 貴之 <tsunakawa(dot)takay(at)fujitsu(dot)com>; 'Kyotaro Horiguchi' <horikyota(dot)ntt(at)gmail(dot)com>; pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: libpq debug log

I tweaked this code a little bit more. I didn't like that libpq-trace.h was exposing all the internal details of the API to the world; and I liked it even less that libpq-int.h had to include the file, exposing everything everywhere. I added some forward struct declarations in libpq-int.h to avoid including libpq-trace.h in it; and I also moved a few of the definitions from libpq-trace.h to the .c file. We didn't really need them to be exposed outside the .c file. In the makefile, libpq-trace.h was being installed in the wrong place -- I changed so that it goes to includedir_internal, like libpq-int.h.

The function pqLogFormatTimestamp was returning a pointer to where it printed things. But that was pointless, because the buffer is caller supplied, so the caller knows full well where the output is. There's no gain in functionality, so I made it return void.

I added a description of the output format to the documentation.

I renamed a lot of functions, so that it looks more like a consistent API. pqTraceMaybeBreakLine() says it returns bool, but it was using "return 1/0" rather than actual bools. That's poor style.

The only thing we're missing here is some coverage. Right now, nothing in the source tree calls this at all, so if we break it, we'll never know. I think we should introduce src/test/modules/test_pqtrace or something like that.

v22 attached.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-02-26 02:59:47 Update docs of logical replication for commit ce0fdbfe97.
Previous Message Greg Stark 2021-02-26 02:40:03 Re: SSL SNI