From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: "Iwata, Aya" <iwata.aya@jp.fujitsu.com>,
        "Jamison,
    Kirk" <k.jamison@jp.fujitsu.com>,
        "Nagaura,
    Ryohei" <nagaura.ryohei@jp.fujitsu.com>,
        Jacob Champion <pchampion@pivotal.io>, Jim Doty <jdoty@pivotal.io>,
        PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
        "nagata@sraoss.co.jp" <nagata@sraoss.co.jp>,
        Haribabu Kommi <kommi.haribabu@gmail.com>,
        Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Subject: Re: libpq debug log
In-reply-to: 
 <CA+TgmobGvUKiNQfh-4GzTWxoD1qX63D3_W3O+fnzBXBCiRSo=g@mail.gmail.com>
References: <71E660EB361DF14299875B198D4CE5423DE3FBA4@g01jpexmbkw25>
 <20180827215124.0cdb4d0cb99136b5a86b1d9f@sraoss.co.jp>
 <71E660EB361DF14299875B198D4CE5423DE4A154@g01jpexmbkw25>
 <4bc9abbd-44a0-1787-b410-4e68b5ab3228@2ndquadrant.com>
 <71E660EB361DF14299875B198D4CE5423DE5ADB3@g01jpexmbkw25>
 <71E660EB361DF14299875B198D4CE5423DE758BB@g01jpexmbkw25>
 <CABAq_6HETsCjv5vf_HXKM+A9smW8P-GVH0iuZ-1Y8RiwQ8eZ+w@mail.gmail.com>
 <71E660EB361DF14299875B198D4CE5423DE804A9@g01jpexmbkw25>
 <71E660EB361DF14299875B198D4CE5423DE82363@g01jpexmbkw25>
 <ae75c8a3-95bd-37d2-bfc1-c0a11b347538@2ndquadrant.com>
 <71E660EB361DF14299875B198D4CE5423DE83937@g01jpexmbkw25>
 <71E660EB361DF14299875B198D4CE5423DE99C79@g01jpexmbkw25>
 <71E660EB361DF14299875B198D4CE5423DEB31F4@g01jpexmbkw25>
 <71E660EB361DF14299875B198D4CE5423DEB9E4B@g01jpexmbkw25>
 <EDA4195584F5064680D8130B1CA91C453BF258@G01JPEXMBYT04>
 <71E660EB361DF14299875B198D4CE5423DED92AD@g01jpexmbkw25>
 <D09B13F772D2274BB348A310EE3027C643BC5C@g01jpexmbkw24> <71E66!
 0EB361DF14299875B198D4CE5423DEDA4CF@g01jpexmbkw25>
 <CA+TgmobviA3E6JH4ohq50FvvL8Lo1=jGKR3t2L196J3CjVeQJg@mail.gmail.com>
 <19535.1550861516@sss.pgh.pa.us>
 <71E660EB361DF14299875B198D4CE5423DEF1844@g01jpexmbkw25>
 <CA+TgmobGvUKiNQfh-4GzTWxoD1qX63D3_W3O+fnzBXBCiRSo=g@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Mon, 04 Mar 2019 22:04:40 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <5007.1551756339.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 04 Mar 2019 22:25:39 -0500
Message-ID: <5008.1551756339@sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> The basic idea being:

> - Each line is a whole message.
> - The line begins with <<< for a message received and >>> for a message =
sent.

+1, though do we really need to repeat the direction marker thrice?

> - Strings in single quotes are those sent/received as a fixed number of =
bytes.
> - Strings in double quotes are those sent/received as a string.
> - 4-byte integers are printed unadorned.
> - 2-byte integers are prefixed by #.
> - I guess 1-byte integers would need some other prefix, maybe @ or ##.

I doubt that anybody gives a fig for those distinctions, except when
they're writing actual code that speaks the protocol --- and I do not
think that that's the target use-case.  So strings and integers seem
like plenty.  I'd also suggest that just because the protocol has
single-letter codes for message types doesn't mean that average users
have memorized those codes; and that framing data like the message
length is of no interest.

In short, rather than

	<<< 'T' 101 4 "Schema" 2615 #2 19 #64 -1 #0 "Name" 1259 #2 19 #64 -1 #0 "=
Owner" 0 #0 19 #64 -1 #0

I'd envision something more like

	< RowDescription "Schema" 2615 2 19 64 -1 0 "Name" 1259 2 19 64 -1 0 "Own=
er" 0 0 19 64 -1 0

> But I still don't really see a need for different levels or whatever.
> I mean, you either want a dump of all of the protocol traffic, or you
> don't, I think.  Or maybe I am confused as to what the goal of all
> this really is.

Yeah, me too.  But a lot of this detail would only be useful if you
were trying to diagnose something like a discrepancy between the server
and libpq as to the width of some field.  And the number of users for
that can be counted without running out of fingers.  I think what would
be of use for a trace facility is as high-level a view as possible of
the message contents.

Or, in other words: a large part of the problem with the existing PQtrace
facility is that it *was* designed to help debug libpq itself, and that
use-case is no longer very interesting.  We should assume that the library
knows how to parse protocol messages.

			regards, tom lane