Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] statement logging / extended query protocol

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Oliver Jowett <oliver(at)opencloud(dot)com>,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] statement logging / extended query protocol
Date: 2005-09-26 02:40:43
Message-ID: 200509260240.j8Q2ehp26926@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-09-26 02:57:58
Subject: Re: [HACKERS] statement logging / extended query protocol
Previous:From: Oliver JowettDate: 2005-09-25 23:27:23
Subject: Re: statement logging / extended query protocol issues

pgsql-patches by date

Next:From: Tom LaneDate: 2005-09-26 02:57:58
Subject: Re: [HACKERS] statement logging / extended query protocol
Previous:From: Oliver JowettDate: 2005-09-25 23:27:23
Subject: Re: statement logging / extended query protocol issues

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group