From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Inconsistency in extended-query-protocol logging |
Date: | 2006-09-13 22:03:39 |
Message-ID: | 17872.1158185019@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com> writes:
> On 9/13/06, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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 see
execute <unnamed>: select ...
followed by
execute 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 : "",
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua Reich | 2006-09-13 22:06:37 | Re: Optimizer improvements: to do or not to do? |
Previous Message | Marshall, Steve | 2006-09-13 21:40:51 | Re: - Proposal for repreparing prepared statements |