RE: libpq debug log

From: "iwata(dot)aya(at)fujitsu(dot)com" <iwata(dot)aya(at)fujitsu(dot)com>
To: "'alvherre(at)alvh(dot)no-ip(dot)org'" <alvherre(at)alvh(dot)no-ip(dot)org>, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>
Cc: 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(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-03-10 05:03:58
Message-ID: TY2PR01MB196364CF9E18269907460BC7EA919@TY2PR01MB1963.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

Following all reviewer's advice, I have created a new patch.

In this patch, I add only two tracing entry points; I call pqTraceOutputMsg(PGconn conn, int msgCursor, PGCommSource commsource) in pqParseInput3 () and pqPutMsgEnd () to output log.
The argument contains message first byte offset called msgCursor because it is simpler to specify the buffer pointer in the caller.

In pqTraceOutputMsg(), the content common to all protocol messages (first timestamp, < or >, first 1 byte, and length) are output first and after that each protocol message contents is output. I referred to pqParseInput3 () , fe-exec.c and documentation page for that part.

This fix almost eliminates if(conn->Pfdebug) that was built into the code for other features.

Regards,
Aya Iwata

> -----Original Message-----
> From: alvherre(at)alvh(dot)no-ip(dot)org <alvherre(at)alvh(dot)no-ip(dot)org>
> Sent: Friday, March 5, 2021 10:41 PM
> To: Tsunakawa, Takayuki/綱川 貴之 <tsunakawa(dot)takay(at)fujitsu(dot)com>
> Cc: 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>; Iwata, Aya/岩田 彩
> <iwata(dot)aya(at)fujitsu(dot)com>; Jamison, Kirk/ジャミソン カーク
> <k(dot)jamison(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
>
> On 2021-Mar-05, tsunakawa(dot)takay(at)fujitsu(dot)com wrote:
>
> > From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
> > > But I think passing the message start address explicitly might be
> > > better than having it understand the buffering behavior in enough
> > > detail to know where to find the message. Part of the point here
> > > (IMO) is to decouple the tracing logic from the core libpq logic, in
> > > hopes of not having common-mode bugs.
> >
> > Ouch, you're perfectly right. Then let's make the signature:
> >
> > void pqLogMessage(PGconn *conn, const char *message, bool
> > toServer);
>
> Yeah, looks good! I agree that going this route will result in more trustworthy
> trace output.
>
> --
> Álvaro Herrera 39°49'30"S 73°17'W

Attachment Content-Type Size
v24-libpq-trace-log.patch application/octet-stream 31.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiro Ikeda 2021-03-10 05:11:49 Re: About to add WAL write/fsync statistics to pg_stat_wal view
Previous Message Thomas Munro 2021-03-10 04:54:41 Re: pgbench: option delaying queries till connections establishment?