Re: Inconsistency in extended-query-protocol logging - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Inconsistency in extended-query-protocol logging
Date
Msg-id 17872.1158185019@sss.pgh.pa.us
Whole thread Raw
In response to Re: Inconsistency in extended-query-protocol logging  ("Guillaume Smet" <guillaume.smet@gmail.com>)
Responses Re: Inconsistency in extended-query-protocol  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
"Guillaume Smet" <guillaume.smet@gmail.com> writes:
> On 9/13/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> statement: querystring                  Simple Query
>> parse <stmt>: querystring               Parse
>> bind <stmt>/<portal>: querystring       Bind
>> execute <stmt>/<portal>: querystring    Execute

> I agree with that.

OK, Bruce hasn't said anything so I went ahead and changed it,
as per attached patch.

> Hmmm, AFAICS, you changed "<stmt>/<portal>" to "<portal> to
> <statement>" in your last commit. Or did I misunderstand?

Yeah, that seemed like a good idea at the time ... but on reflection
it's probably better to be consistent with the way the execute message
is logged.

>> Also, the current code distinguishes a "fetch" from an
>> already-partially-executed portal ... do you care about that?

> I don't really understand what is a portal - I must admit I don't use
> libpq directly. I never saw a log file with fetch. Do you have an
> example? Should I consider an execute from fetch differently?

Well, the point is that if you seeexecute <unnamed>: select ...
followed byexecute fetch from <unnamed>: select ...
the latter is a continuation of the same command not a newly entered
command.  For resource-analysis purposes you can likely treat them the
same, but if you were trying to debug an application you might need to
know the difference.
        regards, tom lane


*** src/backend/tcop/postgres.c.orig    Fri Sep  8 11:55:53 2006
--- src/backend/tcop/postgres.c    Wed Sep 13 17:51:35 2006
***************
*** 1610,1619 ****             break;         case 2:             ereport(LOG,
!                     (errmsg("duration: %s ms  bind %s to %s: %s",                             msec_str,
-                             *portal_name ? portal_name : "<unnamed>",                             *stmt_name ?
stmt_name: "<unnamed>",                             pstmt->query_string ? pstmt->query_string : "<source not stored>"),
                    errdetail_params(params)));             break;
 
--- 1610,1620 ----             break;         case 2:             ereport(LOG,
!                     (errmsg("duration: %s ms  bind %s%s%s: %s",                             msec_str,
           *stmt_name ? stmt_name : "<unnamed>",
 
+                             *portal_name ? "/" : "",
+                             *portal_name ? portal_name : "",                             pstmt->query_string ?
pstmt->query_string: "<source not stored>"),                      errdetail_params(params)));             break;
 
***************
*** 1740,1747 ****         ereport(LOG,                 (errmsg("%s %s%s%s%s%s",
execute_is_fetch?
 
!                         _("statement: execute fetch from") :
!                         _("statement: execute"),                         prepStmtName,
*portal_name? "/" : "",                         *portal_name ? portal_name : "",
 
--- 1741,1748 ----         ereport(LOG,                 (errmsg("%s %s%s%s%s%s",
execute_is_fetch?
 
!                         _("execute fetch from") :
!                         _("execute"),                         prepStmtName,                         *portal_name ?
"/": "",                         *portal_name ? portal_name : "",
 


pgsql-hackers by date:

Previous
From: "Marshall, Steve"
Date:
Subject: Re: - Proposal for repreparing prepared statements
Next
From: Jeremy Drake
Date:
Subject: Re: Getting a move on for 8.2 beta