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: | Raw Message | Whole Thread | 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 |