| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
| Cc: | pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: log_duration |
| Date: | 2005-02-06 17:32:37 |
| Message-ID: | 4984.1107711157@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> Further update on this:
> We've isolated this issue to JDBC client access.
Ah-hah, now it makes sense. I believe the JDBC driver always uses
extended query protocol (parse/bind/execute messages). We know that
that code path is a bit shy of a load with respect to statement logging,
mainly because no one has worked out exactly what it ought to log and
when. When you consider the possibilities for re-use of parsed
statements and partial execution of portals, it's not clear what a
"statement" is, let alone what its "duration" is. Maybe the real
problem is that the GUC variables are defined in terms of a too
simplistic view of the world.
As a quick workaround until someone thinks of a better idea, it might be
sufficient to attach logging code to the execute phase, and ignore the
partial-execution issue.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Daniel Rubio | 2005-02-07 10:34:08 | Problem with permanent connections from Tomcat |
| Previous Message | Simon Riggs | 2005-02-05 23:10:04 | Re: log_duration |