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

Re: Re: [HACKERS] statement logging / extended query protocol

From: <simon(at)2ndquadrant(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Oliver Jowett <oliver(at)opencloud(dot)com>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Re: [HACKERS] statement logging / extended query protocol
Date: 2005-09-26 21:50:01
Message-ID: 28292295$11277696144338660e72a402.42290933@config9.schlund.de (view raw or flat)
Thread:
Lists: pgsql-patches
David Fetter <david(at)fetter(dot)org> wrote on 26.09.2005, 18:31:16:
> On Sun, Sep 25, 2005 at 11:41:11PM -0400, Bruce Momjian wrote:
> > Tom Lane wrote:
> > > Bruce Momjian  writes:
> > > > OK.  At this stage it should all just wait for 8.2.
> > > 
> > > Haven't we already committed some feature changes in this area?  I
> > > dislike the idea of shipping a transient state just because "we
> > > ran out of time".  Once we ship 8.1, that will be another behavior
> > > that we have to consider backwards compatibility with.  We should
> > > either fix it right, or revert to the 8.0 behavior for this
> > > release.
> > 
> > I documented in TODO what doesn't log properly in 8.1.  I don't see
> > how logging output has to be backward compatible.
> 
> Dunno about this particular case, but not having backward-compatible
> logging output has already broken pqa.  Proposal on logging to
> -hackers follows...

Guys,

The changes I initiated, were caused solely by the complete inability of
PostgreSQL 8.0 log files to allow performance tuning for v3 protocol
clients (i.e. JDBC as the main one). That's been a major obstacle for
everybody I have talked to all year. 

I had no wish at all to alter logging, but neither did anyone else, so
something had to be done. Regression to 8.0 way of doing things (i.e.
no logging) is *not* an option unless we want to lose friends, rather
than gain them. So, the log format needs changing... and we have no
need for backwards compatibility.

The current state of logging is that there is sufficient info in the
logs to fully support performance tuning whatever is thrown against the
server, v2 or v3, client or server. Bind parameters are useful but the
use case for that is more to do with debugging support than tuning. So
the current state is that the logging is not in a transient state, its
in a useful end state for an important use case. Though further testing
by all concerned is still required...

Recent changes are only the result of Oliver pointing out a flaw/hole in
the logging for complex v3 query streams. Credit and thanks. Nobody was
planning to do this so late in the day. Least of all myself because I
haven't worked much on the client protocol internals.

(pqa 1.5 is broken. It doesn't even run its sample 7.4 log file
properly. Thats a separate issue to what the log file format is. I do
like 1.4 though.)

A very public thank you to Bruce for running with me on this at every
stage. I think my own name should be secondary to his on the credit,
should those patches stay applied.

Best Regards, Simon Riggs

Responses

pgsql-patches by date

Next:From: David FetterDate: 2005-09-27 06:26:46
Subject: Re: [HACKERS] statement logging / extended query protocol
Previous:From: Joe ConwayDate: 2005-09-26 20:37:04
Subject: Re: Patching dblink.c to avoid warning about open transaction

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