Thread: Re: [HACKERS] Instrumenting and Logging in JDBC
Barry Lind wrote: > 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 >> > >
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 >>> >> >> > >