Re: Instrumenting and Logging in JDBC

From: Barry Lind <blind(at)xythos(dot)com>
To: Bruce Toback <btoback(at)mac(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Instrumenting and Logging in JDBC
Date: 2001-06-25 05:40:42
Message-ID: 3B36CEDA.3060503@xythos.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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
>

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Toback 2001-06-25 05:55:40 Re: JDBC adaptor issue
Previous Message Hannu Krosing 2001-06-25 05:39:04 Re: AW: Re: Re: REPLACE INTO table a la mySQL

Browse pgsql-jdbc by date

  From Date Subject
Next Message Barry Lind 2001-06-25 06:08:33 Re: [HACKERS] JDBC adaptor issue
Previous Message Barry Lind 2001-06-25 04:36:32 Re: [ADMIN] High memory usage [PATCH]