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

 Bruce,

 I agree that log4j is probably overkill.  I also understand the need
 for better logging.  I have been fortunate that I can run through a
 debugger so that I have been able to track down any problems I have
 had when the server sql statment log isn't sufficient.

 The one good thing about postgresql (unlike other databases I use) is
 that at least you have access to the source code so that you can add
 prints as needed.


 thanks,
 --Barry


>> Bruce Toback wrote:
>>
>>>
>>> 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
>>>
>>
>>
>
>