Re: libpq debug log
Alvaro Herrera <alvherre@alvh.no-ip.org>
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: "iwata.aya@fujitsu.com" <iwata.aya@fujitsu.com>
Cc: 'Tom Lane' <tgl@sss.pgh.pa.us>, 'Kyotaro Horiguchi' <horikyota.ntt@gmail.com>, "tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>, "k.jamison@fujitsu.com" <k.jamison@fujitsu.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2021-03-16T15:20:38Z
Lists: pgsql-hackers
On 2021-Mar-15, iwata.aya@fujitsu.com wrote:
> I create protocol message reading function for each protocol message type. (Ex. pqTraceOutputB() read Bind message)
> This makes the nesting shallower and makes the code easier to read.
I'm not sure I agree with this structural change. Yes, it is less
indentation, but these functions are all quite short and simple anyway.
But I don't disagree strongly with it either.
Four issues:
* There's no cross-check that the protocol message length word
corresponds to what we actually print. I think one easy way to
cross-check that would be to return the "count" from the type-specific
routines, and verify that it matches "length" in pqTraceOutputMessage.
(If the separate routines are removed and the code put back in one
giant switch, then the "count" is already available when the switch
ends.)
* If we have separate functions for each message type, then we can have
that function supply the message name by itself, rather than have the
separate protocol_message_type_f / _b arrays that print it.
* If we make each type-specific function print the message name, then we
need to make the same function print the message length, because it
comes after. So the function would have to receive the length (so
that it can be printed). But I think we should still have the
cross-check I mentioned in my first point occur in the main
pqTraceOutputMessage, not the type-specific function, for fear that we
will forget the cross-check in one of the functions and never realize
that we did.
* I would make the pqTraceOutputInt16() function and siblings advance
the cursor themselves, actually. I think something like this:
static int
pqTraceOutputInt16(const char *data, int *cursor, FILE *pfdebug)
{
uint16 tmp;
int result;
memcpy(&tmp, data + *cursor, 2);
*cursor += 2;
result = (int) pg_ntoh16(tmp);
fprintf(pfdebug, " #%d", result);
return result;
}
(So the caller has to pass the original "data" pointer, not
"data+cursor"). This means the caller no longer has to do "cursor+=N"
at each place. Also, you get rid of the moveStrCursor() which does
not look good.
Bikeshedding item:
* I'm not fond of the idea of prefixing "#" for 16bit ints and no
prefix for 32bit ints. Seems obscure and the output looks weird.
I would use a one-letter prefix for each type, "w" for 32-bit ints
(stands for "word") and "h" for 16-bit ints (stands for "half-word").
Message length goes unadorned. Then you'd have lines like this
2021-03-15 08:10:44.324296 < RowDescription 35 h1 "spcoptions" w1213 h5 w1009 h65535 w-1 h0
2021-03-15 08:10:44.324335 < DataRow 32 h1 w22 '{random_page_cost=3.0}'
* I don't like that pqTraceOutputS/H print nothing when !toServer. I
think they should complain.
--
Álvaro Herrera 39°49'30"S 73°17'W
Commits
-
Rename PQtraceSetFlags() to PQsetTraceFlags().
- d0e750c0acaf 14.0 landed
-
Suppress length of Notice/Error msgs in PQtrace regress mode
- e7e341409a3d 14.0 landed
-
Strip file names reported in error messages on Windows, too.
- 53aafdb9ff6a 14.0 landed
-
Fix setvbuf()-induced crash in libpq_pipeline
- a68a894f0198 14.0 landed
-
libpq_pipeline: Must strdup(optarg) to avoid crash
- dde1a35aee62 14.0 landed
-
Remove setvbuf() call from PQtrace()
- 6ec578e60101 14.0 landed
-
Initialize conn->Pfdebug to NULL when creating a connection
- aba24b51cc1b 14.0 landed
-
Disable force_parallel_mode in libpq_pipeline
- a6d3dea8e5e0 14.0 landed
-
libpq_pipeline: add PQtrace() support and tests
- 7bebd0d00998 14.0 landed
-
Improve PQtrace() output format
- 198b3716dba6 14.0 landed
-
Re-simplify management of inStart in pqParseInput3's subroutines.
- d3a557894ce0 11.12 landed
- d2be6cdc55ad 10.17 landed
- a98e53e10dd5 9.6.22 landed
- 56defbdd0f4e 12.7 landed
- 51c54bb60309 14.0 landed
- 3580b4a0cde0 13.3 landed