Hi,
This is a summary of the whole thread.
I am currently improving PQtrace() by adjusting its output to one line per
protocol message as per the advice of reviewers.
Purpose:
If a problem occurs, such as a slow query, you want to know which query takes
time.
In Current libpq, there is
Hi,
I rebased my patch from head. Please find my attached patch.
Regard,
Aya Iwata
v5-libpq-PQtrace-output-one-line.patch
Description: v5-libpq-PQtrace-output-one-line.patch
Hi Kirk,
Thank you for your reviewing.
> Docs:
> It would be better to have reference to the documentations of Frontend/Backend
> Protocol's "Message Format".
I added a link to "Protocol's Message Formats" and little explanation to
PQtrace() documentation.
> Code:
> There are some protocol
Hi Fabien,
I review your patch.
> Add a few tests for the new feature.
+++ b/src/test/regress/expected/psql.out
@@ -4729,3 +4729,46 @@ drop schema testpart;
set search_path to default;
set role to default;
drop role testrole_partitioning;
+--
There is space (+--' '). Please delete it. It
Hi Horiguchi-san,
Thank you for your reviewing.
I updated patch. Please see my attached patch.
> +/* protocol message name */
> +static char *command_text_b[] = {
>
> Couldn't the name be more descriptive? The comment just above doesn't seem
> consistent with the variable. The tables are very
Hi Ram,
I think this documentation helps people who want to understand functions.
>Please find the updated patch. Added to the commitfest as well
I have some comments.
I think some users who would like to know custom function check
src/test/perl/README at first.
How about add comments to the
Hi,
I update patch to improve PQtrace(); output log message in one line.
Please find my attached patch.
How it changed:
> > The basic idea being:
> >
> > - Each line is a whole message.
> > - The line begins with <<< for a message received and >>> for a message
> sent.
> > - Strings in single
Hi,
> The basic idea being:
>
> - Each line is a whole message.
> - The line begins with <<< for a message received and >>> for a message sent.
> - 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.
> -
Hi,
> hio.c:
>
> -saveFreeSpace = RelationGetTargetPageFreeSpace(relation,
> -
> HEAP_DEFAULT_FILLFACTOR);
> +if (IsToastRelation(relation))
> +saveFreeSpace = ToastGetTargetPageFreeSpace();
> +else
> +saveFreeSpace = HeapGetTargetPageFreeSpace(relation);
>
> This
Hi Nikolay,
This patch does not apply. Please refer to http://commitfest.cputube.org/ and
update it.
How about separating your patch by feature or units that can be phased commit.
For example, adding assert macro at first, refactoring StdRdOptions by the
next, etc.
So I change status to
Hi everyone,
I appreciate all the helpful advice.
I agree to display message more clearly. I will follow your advice.
I would like to add timestamp per line and when command processing function
start/end.
I think it is useful to know the application process start/end for diagnosis.
So
Hi Horiguchi-san,
Thank you for your reply and suggestions.
> > 1. Expand PQtrace() facility and improve libpq logging.
> >
> > 2. Prepare "output level". There are 3 type of levels;
> > - TRADITIONAL : if set, outputs protocol messages
> > - LEVEL1: if set, outputs
Hi,
Thank you for your comments and advice.
I'd like to consider your suggestions.
I am planning to change libpq logging like this;
1. Expand PQtrace() facility and improve libpq logging.
2. Prepare "output level". There are 3 type of levels;
- TRADITIONAL : if set, outputs protocol
Hi Robert,
> I'm not really sure that I like the design of this patch in any way.
Aside from problems with my current documentation which I will fix,
could you explain more detail about the problem of the design?
I would like to improve my current implementation based from feedback.
Regards,
Hi Kirk,
> Currently, the patch fails to build according to CF app.
> As you know, it has something to do with the misspelling of function.
> GetTimezoneInformation --> GetTimeZoneInformation
Thank you. I fixed it. Please see my v7 patch.
Regards,
Aya Iwata
Hi Ramanarayana,
Thank you for your review and suggestion. Please see the attached updated patch.
> Issues found while testing
>1) If invalid value is given to PGLOGMINLEVEL, empty log file is created which
>should not happen.
Thank you for your test. However in my dev environment, empty log
Hi,
Because I mistook something about how to reply to e-mails,
my last reply is not reflected in the thread.
Response to Nagaura san's review point, I fixed all his review notes, except
for pointing out about psql.
Please see the attached updated patch.
> 1)
> It would be better making the
Hi,
I am sorry for my late reply.
> I fixed all issues you have reported except using list of supported
> compression
> algorithms.
Sure. I confirmed that.
> It will require extra round of communication between client and server to
> make a decision about used compression algorithm.
In
Hi Nagaura-san,
Thank you for your review and advice.
> This merit was very helpful for my use, so I want your proposal function in
> postgres.
Thank you.
> 1)
> It would be better making the log format the same as the server log format,
> I think.
> Your log format:
> 2019/01/22
Hi,
I have developed a new libpq trace logging aimed at checking which side (server
or client) is causing the performance issue.
The new libpq trace log can do the following things;
- Setting whether to get log or not by using connection strings or environment
variables. It means that
Hi,
I created v5 patch. Please find attached the patch.
This patch updated following items;
- Changed "else if" to "if" in traceLog_fprintf(). This means that both
PQtrace() and new trace log are set, you can get both log result.
- Implemented loglevel with enum. This change makes it easier if
Hi,
> TODO:
> I will add the feature called "logging level" on next version patch. I will
> attach it as soon as possible.
I created v4 patch. Please find attached the patch.
This patch developed "logminlevel" parameter. level1 and level2 can be set,
level1 is the default.
If level1 is set, it
Hi Peter,
Thank you for your reply!
> On 27/11/2018 08:42, Iwata, Aya wrote:
> > I created a new version patch. Please find attached my patch.
>
> This does not excite me. It seems mostly redundant with using tcpdump.
I will develop "log level". I'm planning not to
Hi,
I created a new version patch. Please find attached my patch.
Changes:
Since v2 patch
I forgot to write the detail of v2 patch changes. So I write these.
- Fixed the " Start receiving message from backend:" message location. Because
I found that message located at outside of "retry4".
-
Hi Jacob san,
Thank you for your comment! And sorry for late reply...
> Couple additional thoughts from a read-through of the patch:
>
> - PQtrace() and the new trace-logging machinery overlap in some places but
> not others -- and if both are set, PQtrace() will take precedence.
> It seems
Hi Hari san,
Thank you for your comment! And sorry my late reply…
>I have some comments related to the trace output that is getting
>printed. The amount of log it is generating may not be understood
>to many of the application developers. IMO, this should print
>only the necessary information
Hi Jim Doty san,
Thank you for review! I'm sorry my late reply...
> Initial Pass
>
>
> + Patch applies
> + Patch builds
> + Patch behaves as described in the thread
Thank you for your check.
> When I set a path for `PGLOGDIR` that didn't exist or was not write-able,
> the patch
Hi,
I create a first libpq trace log patch.
In this patch,
- All message that PQtrace() gets are output to the libpq trace log file
(I maybe select more effective message in the future patch)
- Trace log output style is changed slightly from previously proposed
This patch not include
> I didn't find any problems with the patch, so I'm marking it as "Ready for
> Committer".
Sorry, I made a mistake. You patch currently does not apply. Kindly rebase the
patch.
I'm marking it as "Waiting on Author".
Regards,
Aya Iwata
Hi Christoph,
> > All similar function are named pg_ls_***dir. It is clear these
> > functions return directory contents information.
> > If the new function intends to display the contents of the directory,
> > pg_ls_***dir style might be better (e.g. pg_ls_archive_statusdir).
> > But everyone
Hi Christoph,
I think it is convenient to be able to check the archive_status directory
contents information.
I reviewed patch. It applies and passes regression test.
I checked the code.
It refers to the patch which added pg_ls_waldir() and pg_ls_logdir(), so I
think it is good.
There is
Hi,
Sorry for my late response.
> Between perf/systemtap/dtrace and wireshark, you can already do pretty much
> all of that. Have you looked at those and found anything missing?
These commands provide detailed information to us.
However, I think the trace log is necessary from the following
to backend (Result of query, Protocol messages)
(6) Timestamp when information is successfully received in the application
(7) receive message from backend (Result of query, Protocol messages)
(8) Timestamp when SQL ended
Regards,
Iwata Aya
> > I'm going to propose libpq debug log for analysis of queries on the
> > application
> side.
> > I think that it is useful to determine whether the cause is on the
> > application
> side or the server side when a slow query occurs.
>
> Do you mean you want to monitor the protocol message
> "Iwata, Aya" writes:
> > I'm going to propose libpq debug log for analysis of queries on the
> > application
> side.
> > I think that it is useful to determine whether the cause is on the
> > application
> side or the server side when a sl
Hi,
I'm going to propose libpq debug log for analysis of queries on the application
side.
I think that it is useful to determine whether the cause is on the application
side or the server side when a slow query occurs.
The provided information is "date and time" at which execution of
Hello Ildar,
I have a question about failover_timeout parameter.
Which would be better: implementing the parameter to retry at waiting time
or controlling the connection retry on the application side?
Also, I have no idea if the amount of random access by hostorder parameter will
have a good
37 matches
Mail list logo
