Re: [HACKERS] Instrumenting and Logging in JDBC

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(at)optc(dot)com | -- Edna St. Vincent Millay
>>>
>>
>>
>
>