Re: Inconsistency in extended-query-protocol logging

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

In response to

Responses

Browse pgsql-hackers by date

  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