Re: [HACKERS] statement logging / extended query protocol

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