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 |
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? |