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: alvhe...@alvh.no-ip.org <alvhe...@alvh.no-ip.org> > Sent: Friday, March 5, 2021 10:41 PM > To: Tsunakawa, Takayuki/綱川 貴之 <tsunakawa.ta...@fujitsu.com> > Cc: 'Tom Lane' <t...@sss.pgh.pa.us>; Iwata, Aya/岩田 彩 > <iwata....@fujitsu.com>; Jamison, Kirk/ジャミソン カーク > <k.jami...@fujitsu.com>; 'Kyotaro Horiguchi' <horikyota....@gmail.com>; > pgsql-hackers@lists.postgresql.org > Subject: Re: libpq debug log > > On 2021-Mar-05, tsunakawa.ta...@fujitsu.com wrote: > > > From: Tom Lane <t...@sss.pgh.pa.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
v24-libpq-trace-log.patch
Description: v24-libpq-trace-log.patch
