RE: libpq debug log

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

RE: libpq debug log

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 ph

RE: libpq debug log

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 I

RE: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead

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 "Waiti

RE: [PATCH] get rid of StdRdOptions, use individual binary reloptions representation for each relation kind instead

Hi, > hio.c: > > -saveFreeSpace = RelationGetTargetPageFreeSpace(relation, > - > HEAP_DEFAULT_FILLFACTOR); > +if (IsToastRelation(relation)) > +saveFreeSpace = ToastGetTargetPageFreeSpace(); > +else > +saveFreeSpace = HeapGetTargetPageFreeSpace(relation); > > This loc

RE: libpq debug log

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

RE: libpq debug log

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 quo

RE: Contribution to Perldoc for TestLib module in Postgres

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 REA

RE: libpq debug log

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

RE: psql - add SHOW_ALL_RESULTS option

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 is

RE: libpq debug log

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 mess

RE: Function for listing archive_status directory

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 kn

RE: Function for listing archive_status directory

> 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

RE: libpq debug log

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 document

RE: libpq debug log

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 wri

RE: libpq debug log

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 tha

RE: libpq debug log

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 lik

RE: libpq debug log

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

RE: libpq debug log

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

RE: libpq debug log

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 04:15:25

RE: libpq compression

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 beginni

RE: libpq debug 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 lo

RE: libpq debug log

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 fil

RE: libpq debug log

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

RE: libpq debug log

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, Ay

RE: libpq debug log

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 o

RE: libpq debug log

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

RE: libpq compression

Hi, > > I agree with the critiques from Robbie Harwood and Michael Paquier > > that the way in that compression is being hooked into the existing > > architecture looks like a kludge. I'm not sure I know exactly how it > > should be done, but the current approach doesn't look natural; it > > loo

RE: libpq debug log

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 applicati

RE: libpq debug log

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

RE: libpq debug log

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 PQtrace

RE: hostorder and failover_timeout for libpq

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 ef

libpq debug log

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 processin

RE: libpq debug log

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

RE: libpq debug log

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

RE: libpq debug log

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

RE: libpq debug log

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 po

RE: Function for listing archive_status directory

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 one