Re: Instrumenting and Logging in JDBC - Mailing list pgsql-hackers

From Bruce Toback
Subject Re: Instrumenting and Logging in JDBC
Date
Msg-id 200106250516.WAA16686@smtpout.mac.com
Whole thread Raw
In response to Instrumenting and Logging in JDBC  (btoback@mac.com)
List pgsql-hackers
On Sunday, June 24, 2001, at 09:49 PM, Barry Lind wrote:

> First I would ask what kind of logging you are talking about?  
> I find that simply turning on debug output on the server to 
> print out the sql statements being executed is generally all I 
> need for logging, and the server already supports that.

The problem is that the SQL sent to the backend is sometimes the 
end product of a lot of interaction between the JDBC driver and 
the client program. This is frequently the case with 
general-purpose programs like report writers and application 
servers.

If the generated SQL is bad, or if the data the client program 
receives back is bad, it's necessary to figure out exactly what 
the client program is doing in order to solve the problem. For 
example, the client may use some kinds of row metadata and not 
others, or may be using an unusual sequence of calls to place 
data into a PreparedStatement. Logging is the only way to figure 
out what the client is doing if you don't have the client source.

> While logging is a good idea, having yet another non-postgresql 
> component that needs to be installed in order to build and/or 
> run the jdbc driver is in my opionion a bad idea.  I already 
> dislike the fact that I have to install ant just to build the 
> driver.  It was so much easier under 7.0 when make was all that 
> was required.

Agreed -- especially given what it takes to get a Java program 
to work, since there are no standards for where the various 
components should live. Making ant work wasn't a pleasant 
experience: it took more effort to build the 7.1 JDBC driver 
alone than to build the entire 7.0 Postgres suite.

On the other hand, logging *is* useful in making sure that the 
JDBC driver works with the widest possible variety of client 
software, including all kinds of proprietary middleware 
products. If the logging is set up so that log4j is loaded 
dynamically, would that be a satisfactory solution to the build 
problem?

Actually, given the purpose for including logging, log4j is 
probably more than what's required to do the job -- essentially 
just tracing client call activity.

-- Bruce

--------------------------------------------------------------------------
Bruce Toback    Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc.            (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142      | But ah, my foes, and oh, my 
friends -
Phoenix AZ 85028                   | It gives a lovely light.
btoback@optc.com                   |     -- Edna St. Vincent Millay


pgsql-hackers by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: Good name for new lock type for VACUUM?
Next
From: Bruce Toback
Date:
Subject: Re: JDBC adaptor issue