Simon Riggs wrote:
> On Thu, 2005-09-22 at 21:54 -0400, Bruce Momjian wrote:
> > Here are comments on this posting and the patch (it is long):
>
> Thanks for reading through this. I understand now why nobody had gone
> into this detail before...
>
> > > (1)
> > > > Parse (unnamed statement) "SELECT * from pg_proc"
> > > > Bind (unnamed statement -> unnamed portal)
> > > > Execute (unnamed portal, no row limit)
> > >
> > > (1)
> > > jdbc parse
> > > jdbc bind
> > > jdbc execute
> > > LOG: statement: SELECT * from pg_proc
> > >
> > > jdbc parse
> > > jdbc bind
> > > jdbc execute
> > > LOG: statement: SELECT * from pg_proc
> > >
> > > jdbc parse
> > > jdbc bind
> > > jdbc execute
> > > LOG: statement: SELECT * from pg_proc
> > >
> > >
> > > Notice that the parse of the unnamed statement does *not* now generate a
> > > log record.
> >
> > What is the reason for this? I am not so worried about what JDBC uses
> > but what the protocol supports. From my reading of the documentatation
> > is seems to support a single prepare and multiple executes of an unnamed
> > statement.
>
> OK, in terms of the documented protocol, this represents a SimpleQuery
> message. i.e. parse then immediate execute - produces only ONE log of
> the statement.
>
> I agree we should be doing this in terms of the protocol, not the
> driver.
I am confused. I don't see SimpleQuery mentioned anywhere in our
documentation. Is it a JDBC function? Are you saying an unnamed
prepare should only be logged once? Why?
> > Can we get the BIND parameters here? They seem significant for
> > debugging.
>
> Maybe, but I'll punt on this for now in an attempt to not overextend
> myself.
>
> I think this would be best handled with a log_bind_parms = (none | first
> | all) so that all would be happy.
I see no reason they should not always be logged if we are logging
all or mod statements.
> > Should the duration be snprintf into a local buffer and then used in
> > each ereport, rather than duplicating the code three times?
>
> Yes (this was never going to be the final patch...)
OK. At this stage it should all just wait for 8.2. I think the only
missing things we have now is that BIND parameters are not logged, and a
fetch of an already-executed statement appears as another execute.
Added to TODO:
* Allow protocol-level BIND parameter values to be logged
* Allow protocol-level EXECUTE that is actually a fetch to appear
in the logs as a fetch rather than another execute
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
