Re: [HACKERS] Instrumenting and Logging in JDBC

From: Barry Lind <barry(at)xythos(dot)com>
To: pgsql-jdbc(at)postgresql(dot)org
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Instrumenting and Logging in JDBC
Date: 2001-06-25 15:43:36
Message-ID: 3B375C28.3020603@xythos.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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(at)optc(dot)com | -- Edna St. Vincent Millay
>>
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2001-06-25 16:14:59 Re: AW: AW: AW: [PATCH] Re: Setuid functions
Previous Message Barry Lind 2001-06-25 15:43:10 Re: [HACKERS] JDBC adaptor issue

Browse pgsql-jdbc by date

  From Date Subject
Next Message Barry Lind 2001-06-25 17:41:31 Re: RE: [ADMIN] High memory usage [PATCH]
Previous Message Barry Lind 2001-06-25 15:43:10 Re: [HACKERS] JDBC adaptor issue