Re: libpq debug log
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: "k.jamison@fujitsu.com" <k.jamison@fujitsu.com>
Cc: "iwata.aya@fujitsu.com" <iwata.aya@fujitsu.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2021-01-04T14:35:04Z
Lists: pgsql-hackers
Iwata-san,
On Mon, Dec 21, 2020 at 5:20 PM k.jamison@fujitsu.com
<k.jamison@fujitsu.com> wrote:
>
> On Tuesday, December 15, 2020 8:12 PM, Iwata-san wrote:
> > > There are some things still to do:
> > I worked on some to do.
>
> Hi Iwata-san,
>
> Thank you for updating the patch.
> I would recommend to register this patch in the upcoming commitfest
> to help us keep track of it. I will follow the thread to provide more
> reviews too.
>
> > > 1. Is the handling of protocol 2 correct?
> > Protocol 3.0 is implemented in PostgreSQL v7.4 or later. Therefore, most
> > servers and clients today want to connect using 3.0.
> > Also, wishful thinking, I think Protocol 2.0 will no longer be supported. So I
> > didn't develop it aggressively.
> > Another reason I'm concerned about implementing it would make the code
> > less maintainable.
>
> Though I have also not tested it with 2.0 server yet, do I have to download 7.3
> version to test that isn't it? Silly question, do we still want to have this
> feature for 2.0?
> I understand that protocol 2.0 is still supported, but it is only used for
> PostgreSQL versions 7.3 and earlier, which is not updated by fixes anymore
> since we only backpatch up to previous 5 versions. However I am not sure if
> it's a good idea, but how about if we just support this feature for protocol 3.
> There are similar chunks of code in fe-exec.c, PQsendPrepare(), PQsendDescribe(),
> etc. that already do something similar, so I just thought in hindsight if we can
> do the same.
> if (PG_PROTOCOL_MAJOR(conn->pversion) >= 3)
> {
> <new code here>
> }
> else
> {
> /* Protocol 2.0 isn't supported */
> printfPQExpBuffer(&conn->errorMessage,
> libpq_gettext("function requires at least protocol version 3.0\n"));
> return 0;
> }
>
> But if it's necessary to provide this improved trace output for 2.0 servers, then ignore what
> I suggested above, and although difficult I think we should test for protocol 2.0 in older server.
>
> Some minor code comments I noticed:
> 1.
> + LOG_FIRST_BYTE, /* logging the first byte identifing the
> + * protocol message type */
>
> "identifing" should be "identifying". And closing */ should be on 3rd line.
>
> 2.
> + case LOG_CONTENTS:
> + /* Suppresses printing terminating zero byte */
>
> --> Suppress printing of terminating zero byte
>
The patch got some review comments a couple weeks ago but the patch
was still marked as "needs review", which was incorrect. Also cfbot[1]
is unhappy with this patch. So I'm switching the patch as "waiting on
author".
Regards,
[1] http://commitfest.cputube.org/
--
Masahiko Sawada
EnterpriseDB: https://www.enterprisedb.com/
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