Thread: Instrumenting and Logging in JDBC
Hi all, One more question/comment. In order to track down the problem with the interaction between WebObjects and the PostgreSQL JDBC driver, I had to insert a fair amount of logging. This logging will be useful for anyone else who's in a similar position, trying to get some piece of middleware to work with PostgreSQL. If I switch to using log4j (see http://jakarta.apache.org/log4j for information), would it be useful to submit the logging calls as a patch? I think it would be extremely useful, but I don't know the philosophies or mindset of the PostgreSQL developers, so I thought I'd ask. -- 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
I would like to see the calls, please submit them Dave -----Original Message----- From: pgsql-hackers-owner@postgresql.org [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of btoback@mac.com Sent: June 23, 2001 7:38 PM To: pgsql-hackers@postgresql.org Subject: [HACKERS] Instrumenting and Logging in JDBC Hi all, One more question/comment. In order to track down the problem with the interaction between WebObjects and the PostgreSQL JDBC driver, I had to insert a fair amount of logging. This logging will be useful for anyone else who's in a similar position, trying to get some piece of middleware to work with PostgreSQL. If I switch to using log4j (see http://jakarta.apache.org/log4j for information), would it be useful to submit the logging calls as a patch? I think it would be extremely useful, but I don't know the philosophies or mindset of the PostgreSQL developers, so I thought I'd ask. -- 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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
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
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. > > If your proposal it so use log4j for logging, then I would be opposed. > 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. > > thanks, > --Barry > > > btoback@mac.com wrote: > >> Hi all, >> >> One more question/comment. >> >> In order to track down the problem with the interaction between >> WebObjects and the PostgreSQL JDBC driver, I had to insert a fair >> amount of logging. This logging will be useful for anyone else who's >> in a similar position, trying to get some piece of middleware to work >> with PostgreSQL. If I switch to using log4j (see >> http://jakarta.apache.org/log4j for information), would it be useful >> to submit the logging calls as a patch? >> >> I think it would be extremely useful, but I don't know the >> philosophies or mindset of the PostgreSQL developers, so I thought I'd >> ask. >> >> -- 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 >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 5: Have you checked our extensive FAQ? >> >> http://www.postgresql.org/users-lounge/docs/faq.html >> > >
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 >>> >> >> > >
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. If your proposal it so use log4j for logging, then I would be opposed. 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. thanks, --Barry >> >> btoback@mac.com wrote: >> >>> Hi all, >>> >>> One more question/comment. >>> >>> In order to track down the problem with the interaction between >>> WebObjects and the PostgreSQL JDBC driver, I had to insert a fair >>> amount of logging. This logging will be useful for anyone else who's >>> in a similar position, trying to get some piece of middleware to work >>> with PostgreSQL. If I switch to using log4j (see >>> http://jakarta.apache.org/log4j for information), would it be useful >>> to submit the logging calls as a patch? >>> >>> I think it would be extremely useful, but I don't know the >>> philosophies or mindset of the PostgreSQL developers, so I thought >>> I'd ask. >>> >>> -- 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 >>> >>> ---------------------------(end of broadcast)--------------------------- >>> TIP 5: Have you checked our extensive FAQ? >>> >>> http://www.postgresql.org/users-lounge/docs/faq.html >>> >> >> > >
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 >