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
> 



Sun, 24 Jun 2001 22:40:42 -0700
Barry Lind <blind@xythos.com>
Re: 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
>>
> 
> 



Mon, 25 Jun 2001 08:43:36 -0700
Barry Lind <barry@xythos.com>
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@optc.com                   |     -- Edna St. Vincent Millay
>>>
>>
>>
> 
> 



Mon, 25 Jun 2001 15:49:51 -0700
Barry Lind <barry@xythos.com>
Re: [HACKERS] Instrumenting and Logging in JDBC