RE: libpq debug log

From: "iwata(dot)aya(at)fujitsu(dot)com" <iwata(dot)aya(at)fujitsu(dot)com>
To: "'pgsql-hackers(at)lists(dot)postgresql(dot)org'" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: RE: libpq debug log
Date: 2020-12-15 11:11:58
Message-ID: TY2PR01MB1963C382F0EC579CD409EF13EAC60@TY2PR01MB1963.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Alvaro san,

> There are some things still to do:
I worked on some to do.

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

> 5. Error messages are still printing the terminating zero byte. I
> suggest that it should be suppressed.
I suppressed to print terminating zero byte like this;
2020-12-15 00:54:09 UTC < ErrorResponse 100 S "ERROR" V "ERROR" C "42P01" M "relation "a" does not exist" P "15" F "parse_relation.c" L "1379" R "parserOpenTable" 0

I thought about not outputting it, but the document said that if zero,
it was the last message, so I made it output "0".

> 6. Let's redefine pqTraceMaybeBreakLine() (I renamed from
> pqLogLineBreak):
Sure. I redefined this function.

> 7. Why does it make sense to call pqTraceMaybeBreakLine when
> commsource=FROM_FRONTEND?
Backend messages include break line. However frontend messages don’t have it. So I call this functions.

Pending lists.
> 0. XXX comments
There were 4 XXX comments in Alvaro san's patch. 3 XXX comments are left in current patch.
I will answer this in next e-mail.

> 2. We need a mode to suppress print of time;
> 3. COPY ... (FORMAT BINARY) emits "invalid protocol" ... not good.
> 4. Even in text format, COPY output is not very useful. How can we
improve that?

Regards,
Aya Iwata
Fujitsu

Attachment Content-Type Size
v10-0001-libpq-trace.patch application/octet-stream 22.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2020-12-15 11:21:55 Re: REINDEX backend filtering
Previous Message Alexey Kondratov 2020-12-15 10:34:35 Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly