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